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INTRODUCTION 
The  Acquisition  Process 


During  the  next  decade  we  are  going  to  field  over  400  new  systems  into  the  defense 
inventory.  Many  of  these  systems  will  either  replace  older  ones,  support  existing  ones,  or 
be  both  new  in  technology  and  utilization  against  a  new  threat.  The  threat  itself  will  have 
the  most  impact  on  acquisition  decisions,  but  there  are  many  other  factors  to  be 
considered.  In  a  macro  sense  the  life  cycle  of  major  system  acquisition  can  be  shown  as 
depicted  in  Figure  I J  Some  factors  that  impact  this  system  are  the  threat,  Congressional 
actions,  foreign  policy,  inflation  or  the  media.  Internal  to  OSD  we  have  factors  such  as 
funding,  the  user's,  test  facilities,  OSD  and  service  decisions. 

Present  in  both  the  external  and  internal  environments  of  system  acquisition  are  the 
relationships  of  individuals  and  organizations.  The  communications,  formal  or  informal, 
written  or  spoken  are  representative  of  these  relationships.  The  perspectives  from  which 
any  individual  or  organization  interfaces  with  the  acquisition  process  are  key  to  the 
degree  to  which  a  factor  may  impact  that  process.  With  people  as  individuals  and 
individuals  making  ip  organizations,  both  will  have  particular  biases  and  perceptions  as 
they  carry  out  their  functions  in  system  acquisition.  Recently  a  Senator  related  that  his 
strong  interest  in  the  procurement  of  a  weapon  was  due  to  an  emotional  experience  he  had 
during  the  Korean  War.  He  was  concerned  that  a  future  soldiers  life  may  depend  on  this 
new  weapon  system  and  he  wanted  it  to  do  its  job.  Therefore,  what  we  have  is  an 
acquisition  process  developed  and  changing  due  to  the  perspectives  and  biases  of 
individuals  and  organizations,  communicated  sometimes  effectively  or  ineffectively. 


Figure  I 

Life  Cycle  of  Major  Acquisition 
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In  the  acquisition  business  the  Program  Manager  (PM)  is  saddled  with  integrating 
acquisition  functions  from  the  development  of  strategy  prior  to  program  initiation,  to 
supporting  the  system  and  conducting  product  improvement  after  system  deployment. 
This  integration  process  can  be  visualized  as  Figure  2. 


Figure  2 

Acquisition  Integration 


As  the  system  moves  through  the  process,  not  only  are  there  different  development 
phases  for  the  system,  but  different  organizations  end  individuals  involve  themselves  in 
varying  actions.  OSD  reviews  and  DSARC  decisions,  OMB  audits,  laboratory  studies, 
personnel  offices,  the  "30  Minute  Expert,"  all  of  which  impact  the  acquisition  process  and 
whose  impact  must  be  managed  by  the  PM.  To  add  to  this  complexity,  the  "players"  are 
changing,  thus  changing  the  perception  and  biases  that  must  be  understood  when 
integrating  their  impact  on  the  PM’s  program. 

In  many  programs  the  PM  is  also  one  who  is  here  today  and  gone  tomorrow.  A 
recent  review  of  nine  major  systems  in  the  Army  showed  PM's  averaging  12-18  months. 
None  of  the  changes  were  due  to  failures,  but  for  career  development  and  a  priority  need 
for  the  PM  in  another  job.  This  requires  the  PM  to  hove  an  almost  immediate 
understanding  of  the  system,  organizations,  people,  and  how  they  interoct.  And,  to 
continually  sense  the  environment,  analyze  change,  and  make  integration  decisions  to 
effectively  navigate  the  system  through  acquisition. 


Issue  Statement 


If  the  elements  outlined  above  exist  for  PM's  in  the  acquisition  process,  how  ore  the 
impacts  analyzed  and  skills  or  knowledge  applied  to  this  integration  process?  What  are 
some  of  the  skills  necessary  to  accomplish  these  tasks?  What  resources  are  available  to 
the  PM  to  acquire  or  improve  these  skills/knowledge  base  and  assist  in  the  integration. 
Finally,  what  will  the  future  bring  to  support  the  PM? 

Research  Objectives 

The  objectives  of  this  research  are  as  follows: 

1.  To  model  a  generic  Program  Management  Office  (PMO)  and  the  system  for 
which  it  is  an  element.  This  model  will  systematically  illustrate  the  integration  and 
necessary  interfaces  of  the  human,  organizational,  and  technical  aspects  of  program 
management. 

2.  To  utilize  the  model  as  a  baseline  to  identify  or  develop  skills  and  method¬ 
ologies  the  PM  might  use  to  manage  this  integration. 

3.  To  identify  resources  as  they  apply  to  the  skills  and  methodologies  we  have 
identified. 

It  is  desired  that  this  document  might  serve  as  a  resource  for  PM's  and  their  PMO's, 
and  support  the  instructional  philosophy  of  the  Defense  Systems  Management  College 
(DSMC). 


Methodology 

The  model  developed  will  be  based  on  logical  conclusions  and  data  obtained  through 
the  use  of  a  questionnaire  distributed  to  individuals  in  the  field  of  system  acquisition. 
This  will  require  an  understanding  of  the  integration  responsibility  of  program  manage¬ 
ment  and  the  interfaces  present  in  system  acquisition.  This  mjdel  will  establish  a 
common  understanding  before  proceeding  to  identify  and  develop  methodologies  and  skills 
for  program  management. 

It  is  the  intention  of  this  research  that  the  methodologies  and  skills  do  not  imply  a 
"cookbook"  approach  to  program  management.  But  does  generote  a  desire  to  examine  new 
ideas  and  project  some  future  ideas  to  enhance  program  management. 

The  development  steps  will  be: 

1 .  Take  a  macro  view  of  the  interface  in  depth  found  in  program  management. 

2.  Depict  the  internal  interface  with  organizations,  people,  and  the  sys¬ 
tem/product  domains. 

3.  Describe  the  interface  boundary  factors  and  how  they  may  hinder  effective 
interaction. 


4.  Examine  the  multiplicity  of  program  integration  by  taking  points  in  time  and 
summing  the  impacts  each  will  have  on  the  Program  Manager's  decision-making  process. 

5.  Finally,  to  add  the  dimensionality  found  in  the  life  cycle  of  system  acquisition, 
to  the  interface  in  depth  of  program  management. 

The  final  product  will  be  the  Multi-Dimensional  Program  Management  Model. 


PROGRAM  MANAGEMENT  QUESTIONNAIRE 


In  the  development  of  the  Multi-Dimensional  Program  Management  Model,  an  initial 
concept  paper  was  sent  out  with  a  questionnaire  to  validate  the  concept.  This  validation 
strategy  provided  feedback  on  the  reality  of  the  model  and  recommendations  to  modify 
elements  based  on  reality.  The  following  groups  of  people  were  requested  to  respond: 

•  Program  Managers 

•  DOD  personnel  attending  the  Executive  Refresher  Course,  DSMC 

•  Faculty  of  DSMC  with  program  management  experience 

•  Students  attending  the  Program  Management  Course,  DSMC 

The  questionnaire  was  designed  in  the  first  section  to  provide  demoqraphic 
information  on  the  individuals  experience  and  service,  and  a  brief  description  of  their 
program(s).  The  second  section  provided  feedback  on  the  reality  and  effectiveness  of  the 
model  in  the  concept  paper.  It  also  provided  data  on  the  agreement  of  goals  and  the 
understanding  of  responsibilities  among  people  and  organizations  related  to  their  program. 
Finally,  this  section  provided  feedback  on  change  for  the  model  and  general  comments  by 
the  respondents  on  program  management.  A  copy  of  the  concept  paper  and  questionnaire 
are  at  Appendix  A.  The  data  obtained  and  a  discussion  of  selected  data  are  at  Appendix 
P. 


MULTI-DIMENSIONAL  PROGRAM  MANAGEMENT 

Model  Development 

People  make  up  our  system  acquisition  programs  of  which  the  system  is  the  product 
of  their  integrated  efforts.  The  ease  with  which  that  integration  takes  place  can  be 
measured  subjectively  by  (I)  how  well  the  formal  and  informal  communications  process 
functions,  (2)  how  congruent  goaL  c,.d  objec lives  are,  and  (3)  how  well  understood  roles 
and  responsibilities  are  for  individuals  and  organizations.  To  manage  the  integration 
process  is  to  recognize  the  actual  interface  and  logically  apply  skills  to  measure  the 
effectiveness  of  this  interface.  Then  utilize  different  skills  to  enhance  the  interface. 
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Figure  3 


Interface  in  Depth 


Although  there  are  many  more  areas  that  could  be  depicted  in  Figure  3,  just 
accepting  these  indicates  there  are  7  elements  of  the  people  domain,  15  in  the 
organizational,  and  14  in  the  system.  This  could  equate  to  1,470  possible  interface 
relationships  for  the  PM  to  integrate. 

Hearing  this  the  first  time,  some  have  questioned  the  responsibility  of  the  PM  to 
integrate  Congress  into  system  acquisition.  The  law  accomplishes  this.  But  ,the  PM  will 
integrate  the  impact  of  Congressional  decisions,  particularly  funding,  into  the  acquisition 
program.  The  actual  interface  could  have  several  scenarios;  PM  testifies  before 
Congress,  System  Acquisition  Report  (SAR)  is  reviewed  by  a  committee,  the  PM  briefs  a 
staffer  or  service  congressional  liaison  officer,  and  many  more.  The  bottom  line  will  be 
the  decisions  and  resultant  actions  from  which  an  impact(s)  will  have  to  be  integrated. 

Simply  put,  it  takes  people  to  make  organizations,  who  interact  to  acquire  systems 
which  involve  subsystems,  and  are  made  for  people  to  use.  Since  the  interfaces  are 
multiple  and  indepth,  it  will  take  multiple  strategies  to  manage  this  interaction. 

If  the  hierarchy  of  systems  model  is  used  to  evaluate  Figure  3,  then  the  people 
domain  becomes  a  subset  of  the  organizational  domain.  The  representation  here  is  in  how 
each  of  the  domains  interact  and  the  resultant  impact  of  their  interaction.  Breaking  each 
of  these  domains  apart  gives  another  level  of  interaction  which  satisfies  the  hierarchy  of 
systems  model.  Figure  4,  People  Domain  shows  the  interact  between  elements  which 
make  up  an  organization  or  are  representatives  of  different  organizations.  When  the 
integration  takes  place,  the  elements  are  understood  to  have  their  own  values,  biases, 
behavior,  etc.,  and  this  will  be  translated  into  an  organizational  set  of  values,  biases, 
behavior,  etc.  An  example  of  this  organizational  interaction  is  at  Figure  5. 


Figure  4 
People  Domain 
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Figure  5 

Organizational  Domain 


In  this  organizational  example,  the  PM  is  responsible  for  taking  the  impacts  of  these 
elements  and  integrating  them  into  the  acquisition  program. 

•  The  contractor  can  influence  Congressional  decision-making  as  a  constituent 
of  a  particular  Congressman  or  Senator. 

•  The  user  con  be  called  to  testify  or  is  interviewed  by  a  staffer  as  part  of 
Congressional  decision-making. 

•  The  user  can  provide  input  into  the  contractor  design.  The  contractor's 
capabilities  can  drive  the  utilization  of  the  system. 

These  interactions  may  or  may  not  physically  take  place,  but  the  PM  will  be  integrating 
their  communicated  information,  decisions,  and  actions  as  impacts  on  the  system 
acquisition  program. 

So  far  each  of  the  domains  presented  here  have  been  people  or  consist  of 
groups/organizations  of  people.  The  system  or  product  is  olso  a  domain  thot  has  internal 
interfaces.  Figure  6  are  examples  of  possible  system  integrations. 


Figure  6 
System  Domain 


The  hardware  and  software  interfaces  can  be  extremely  delicate  in  the  design  and 
performance  of  a  system.  And  the  effectiveness  of  these  interfaces  can  be  directly 
affected  by  the  dollar  resources  available.  The  second  example  shows  the  known  threat 
impacting  the  sub-system  design  and  vica  versa,  the  sub-systems  being  designed  to  meet 
the  known  threat.  The  unknowns  present  themselves  as  the  limits  of  state-of-the-art  or 
unknown  changes  in  the  threat.  Several  people  in  many  organizations  will  be  working  on 
the  system  domain,  but  the  PM  integrates  their  impacts. 

Earlier  the  effectiveness  of  an  interface  was  mentioned  as  a  measure  of  the 
integration  within  the  domains  or  among  the  domains.  If  this  is  to  be  used,  a  description 
of  the  interface  is  appropriate.  As  an  example,  elements  of  the  organizational  and  system 
domains  will  be  used.  Figuie  7  depicts  the  interaction  of  the  contractor  with  the  known 
threat. 
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Figure  7 

Interface  Boundary  Representation 


With  the  identification  of  the  threat,  a  people  on d  organizational  process 
supplemented  by  system  technology,  a  need  is  communicated  to  potential  contractors. 
Generally,  this  is  in  the  form  of  an  RFP  written  by  the  PMO.  In  some  instances  it  can  he 
in  other  formal  or  informal  communication  mediums  when  the  government  is  unsure  of  the 
nature  of  the  threat  or  the  existing  state-of-the-art  to  meet  the  threat.  The  effective¬ 
ness  of  an  int<  -face  between  the  contractor  and  the  threat  will  be  dependent  on  the 
existence  of  a  boundary  which  hinders  their  interaction.  And,  there  will  be  factors  that 
contribute  to  the  density  of  this  boundary.  To  visualize  the  boundary  effects,  picture  a 
chain  link  fence  where  communication  and  visual  sensing  can  take  place  versus  a  tall 
concrete  wall  where  interaction  is  almost  non-existent. 

In  the  contractor-threat  example,  the  density  of  the  boundary  may  be  affected  by 
the  openness  of  communications,  the  state-of-the-art  in  threat  identification,  corporate 
goals  of  the  contractor,  politics,  and  possible  others.  The  PM  will  seek  to  reduce  the 
boundary  density  by  coordinating  open  communication,  seeking  additional  assistance  in 
threat  identification,  and  having  an  understanding  of  corporate  and  governmental  politics. 

A  second  scenario  could  involve  DOD  civilians  and  DOD  personnel  regulations  and 
directives.  Their  interaction  is  seen  in  Figure  Pa.  Here  the  PM  must  manage  his  civilian 
work  force  according  to  DOD  guidance.  The  boundary  factors  may  become  freeze  and 
hiring  restrictions,  the  ability  to  effectively  deal  with  unproductive  personnel,  or  the 
ability  to  properly  reward  those  that  have  contributed  outstandingly.  The  only  tool  a  PM 
may  have  to  reduce  boundaries  may  be  communications  up  and  down  to  gain  support  for 
decisions. 


The  interfaces  do  not  have  to  cross  domains  to  have  an  interaction.  Figure  8b  is  an 
example  of  two  organizations  interacting.  Here  the  PM  must  integrate  the  coordination 
of  GFF  or  GFM  for  the  prime  contractor's  use.  An  issue  of  organizational  goals  or 
responsibilities  may  occur  ny  boundary  fat  tors  increasing  boundory  density  if  goals  are  not 
i  augment  or  responsibilities  understood. 


8(A) 


8(B) 


Figure  8 

Domain  Interfaces 


Up  to  this  point,  a  series  of  examples  have  been  presented  to  illustrate  interface  and 
potential  boundaries.  Since  the  interfaces  are  multiple,  a  listing  of  potential  boundary 
factors  may  be  in  order.  Each  domain  has  a  set  of  boundary  factors  but  those  for  the 
People  and  Organizational  domains  are  very  similar.  Again,  this  is  due  to  organizations 
being  made  up  of  people;  and  when  they  come  to  the  organization,  they  bring  in  their 
values,  biases,  behavior  which  contribute  to  those  of  the  organization. 


SYSTEMS/PRODUCT 


ORGANIZATIONAL 

Organizational  values 
Biases 

Perspectives 
Organizational  goals 
Expectations 
Needs  and  desires 
Organizational  behavior 
Politics 

Regulations  and  Directives 

Organizational  structure 

Communications 

Facilities 

Media 

Priorities 

Organizational  Resources 

Ownership/Propriety 

Others 


Technology  State-of-the-Art 
The  Threat  Assessment  Capabilities 
Available  Resources 
Authorized  $$$ 

Appropriated  $$$ 

Design  Capabilities 

Engineering  Capabilities 

Manufacturing  Capabilities 

Contracts 

T&E 

Quality 

Training 

Maintenance  Capabilities 
Support  Capabilities 
Others 


PEOPLE 

Individual  Values 
Biases 

Perspectives 
Individual  behavior 
Needs  and  Desires 
Expectations 
Communications 
Personnel  Regulations 
Personnel  Resources 
Accountibility 
Rewardability 
Mobility 

Management  Styles 
Personal  Abilities/Willingness 
Others 


Figure  9 

Boundary  Factors 
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With  an  understanding  of  interface,  boundaries,  and  boundary  factors,  and  the 
acceptance  of  the  PM's  role  in  integrating  the  impacts  of  the  domains  and/or  their 
elements,  the  next  step  is  to  take  snapshots  in  time  to  see  the  phasing  of  the  PM's 
environment.  Figure  10  represents  three  scenarios  the  PM  could  be  managing  for  whirl) 
the  boundary  factors  would  have  to  be  recognized  in  order  to  effectively  manage  each 
situation. 


Figure  10 

Dynamic  transitioning  of  Interface  Management 


Figure  10  starts  off  with  an  Integrated  Logistics  Support  issue  in  the  system  domain. 
The  PM  is  dealing  with  the  dollars  required  to  effectively  supply  parts  and  spares  to 
support  the  system  upon  deployment.  This  issue  is  then  transitioned  to  a  funding  issue  to 
include  these  dollars  in  an  upcoming  budget  request  for  Congressional  approval.  This 
represents  an  interface  between  two  elements  of  the  organizational  domain,  Congress  and 
OSD,  and  dollars  from  the  system  domain.  Finally,  the  ILS  issue  is  a  focal  point  for  a 
conflict  issue  within  the  people  domain.  The  PM  has  to  manage  the  interface  between  the 
Senior  Engineer  who  is  pushing  the  performance  design  and  the  Logistics  Manager  who  is 
seeking  support  considerations  in  the  design.  The  Business  Manoger  is  setting  further 
bounds  by  injecting  the  dollar  constraints  of  the  program.  These  scenarios  depict  the 
dynamic  transitioning  a  PM  must  go  through  when  managing  interfaces  between  the 
people,  organizational,  and  system  domains. 


The  Multi-Dimensional  Program  Management  Model 

To  complete  the  model,  time  must  now  be  continuous.  Taking  the  graphics  from 
Figure  I,  the  life  cycle  of  system  acquisition,  and  Figure  3  on  interface  in  depth,  the 
dimensionality  is  coupled  with  time.  The  graphic  result  is  Figure  1 1. 
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time,  a  discussion  is  required. 


During  the  life  cycle  of  system  acquisition,  particular  domains  may  be  more 
dominant  than  others.  Coupling  this  idea  with  the  symbology  of  Figure  10,  interfaces  are 
changing  as  situations  change,  the  result  would  appear  enharmonic.  Frequency  and 
amplitude  of  the  integration  changing  as  a  result  of  situational  change. 


This  notion  is  reinforced  by  data  in  the  questionnaire.  Several  respondents  wrote  of  the 
continuous  change  and  flexibility  of  the  interfaces  they  managed.  This  equates  to  the 
influence  a  particular  domain  or  element  may  have  on  the  integration  at  any  moment 
during  system  acquisition.  An  analysis  could  sum  up  this  transition  and  influence  as 


follows: 

Acquisition  Phase 

Domain  Influence  on  Integration 

• 

Program  Initiation 

People  emphasis  in  gettinq  the  right  ones  to 
conceptualize  solutions. 

• 

Demonst  ra  t  i  on/ Va  1  i  dat  ion 

Organizational  dominate  as  organization's 
power  and  capabilities  come  into  play. 
Systems  and  people  still  very  important. 

• 

Full  Scale  Development 

Systems  dominate  with  organizations  being 
important  as  production  contracts  are 
considered. 

• 

Production/Deployment 

Organizations  and  system  dominate  as 
people  influence  decreases. 

• 

Beyond  Deployment 

Organizations  dominate,  system  is 
somewhat  important,  and  people  influence 
low. 

In  summary,  the  Multi-Dimensional  Program  Management  Model  is  a  combination  of 
those  graphics  presented  in  Figure  3  —  Interface  in  Depth,  Figure  7  —  Interface  Boundry 
Representation,  Figure  I  I  --  Multi-Dimensional  Program  Management,  and  the  following 
points: 

•  Boundaries  have  densities  that  are  expanded  or  reduced  by  boundary  factors. 
The  size  of  the  density  indicates  the  effectiveness  of  the  integration. 

•  Interfaces  are  transitioning  and  domain  influence  varies  with  the  situation.  A 
summation  of  this  transition  and  influence  may  indicate  a  general  dominance 
pattern. 

•  Finally,  the  Program  Manager  may  in  actuality  directly  integrate  the  functions 
and  actions  of  only  a  portion  of  the  elements  in  the  people,  organization,  and 
system  domains.  But,  he/she  is  responsible  for  integrating  the  impacts  of  all 
elements  of  the  domains  on  the  acquisition  of  his/her  system. 


Utilizotioo  of  M-DPM  Model 


Program  Management  is  dynamic  in  its  simplest  of  forms.  The  aspects  of  major  vs. 
non-major  acquisition,  joint  vs.  sole  service  acquisition,  and  the  added  dimension  of 
Foreign  Military  Sales  (FMS)  merely  complicates  an  already  complex  environment.  This 
complexity  requires  the  identification  of  interfaces,  a  skill  that  must  be  developed  by  the 
PM  and  his  staff.  The  system  interfaces  generally  are  quite  visible,  they  fit/don't  fit, 
there  are  enough/not  enough  resources,  etc.  The  organizational  and  people  interfaces  are 
much  harder  to  distinguish  with  the  fluid  and  less  definable  environments  of  system 
acquisition. 

An  understanding  of  the  M-DPM  Model  and  its  implications  could  assist  in  interface 
recognition.  One  senior  PM  responded  to  the  questionnaire  by  stating  that  the  principles 
of  the  M-DPM  Model  helped  him  to  identify  the  most  sensitive  interfaces  at  any  given 
time.  This  can  be  accomplished  by  understanding  the  following: 

•  Who  or  what  constitutes  the  interface? 

•  What  is  their  position  in  the  interface? 

•  What  possible  actions  may  result  from  this  interface? 

•  How  effective  is  the  interface  based  on  known  boundary  factors? 

•  Finally,  what  are  the  potential  impacts  on  my  program? 

To  supplement  this  analysis,  the  PM  should  also  have  a  strategy  based  on  what  is 
desired  from  the  interface  and  how  can  the  PM/PMO  affect  the  interface. 

I  personally  do  not  expect  PM's  or  their  staff  to  embrace  M-DPM  as  the  tool  to  solve 
all  problems  and  situations.  The  principles  though,  should  be  considered  with  all  other 
skills  and  knowledge  a  PM  utilizes  to  manage  the  acquisition  environment.  It  also 
becomes  an  effective  way  of  communicating  the  complexity  of  program  management  to 
those  who  are  unfamiliar  with  it. 

As  mentioned,  the  model  is  a  sensing  tool;  it  describes  the  environment.  Therefore, 
many  other  skills  are  necessary  which  will  be  discussed  next. 
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MANAGEMENT  METHODOLOGIES  AND  SKILLS 


No  Cookbook 

As  stated  earlier,  the  methodo.ogies  and  skills  presented  in  this  research  paper  are 
not  to  be  construed  as  a  complete  kit  baq  or  cookbook  for  the  PM  or  PMO.  Rut,  to 
generate  a  desire  to  examine  ideas;  some  old,  some  new,  and  to  take  a  look  into  the  future 
of  program  management.  If  we  accept  the  M-DPM  Model,  the  use  of  methodologies  and 
skills  may  look  like  Figure  13. 


Figure  13 

Breaking  Down  Interface  Boundries 


The  PM  as  a  Navigator 

The  PM  is  the  leader  that  takes  the  PMO  and  the  system  through  the  acquisition 
cycle.  He  develops  and  maintains  an  effective  team  made  up  of  many  roles  —  scouts, 
pacernen,  planners,  problem  solvers,  and  implementors,  each  moving  along  his/her  course. 
As  the  ship  passes  through  rough  waters  or  unfavorable  winds,  the  PM  must  analyze  Iheir 
impact  and  chart  a  new  course.  This  requires  a  keen  understanding  of  the  destination  and 
the  environment. 


The  path  can  be  charted  through  effective  planning  at  various  levels  as  an  active, 
not  passive,  function.2  The  planning  stages  are: 

•  Level  I  -  Normative  Planning 

This  is  the  goal-setting  and  problem  definition  phase  characterized  by  the 
guestions,  "Where  should  we  be,  and  why?" 

•  Level  II  -  Strategic  Planning 

This  is  the  phase  where  resources  are  identified  and  potential  obstacles  ore 
analyzed.  Here  the  guestions  are,  "Where  can  we  be,  and  how?" 

•  Level  III  -  Operational  Planning 

During  this  phase  time  schedules,  impacts  of  decisions  and  actions,  and 
available  resources  ($$$,  personnel,  etc.)  are  analyzed.  The  guestions  are, 
"Where  will  we  be,  when,  and  in  what  configuration?" 

To  understand  the  environment  through  which  the  course  is  charted  requires  a 
systematic  approach.  From  the  inside  looking  out,  the  Multi-Dimensional  Program 
Management  Model  is  a  tool.  From  the  outside  looking  in,  the  Open  System  Model  is 
effective.  Figure  14  reflects  this  model  in  a  manner  the  PM  may  view  his  system  and  its 
environment. 
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Figure  14 

A  PM’s  Open  System 
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By  developing  a  picture  of  what  the  PM  and  PMO  are  dealing  with  and  effectively 
planning  at  each  level,  the  course  will  be  plotted  and  destination  known.  To  get  there  will 
require  the  integration  of  "systems"  leaders  across  organizational  boundaries  to  manage 
critical  interfaces.  3  They  will  have  to  syncronize  their  actions  through  goal  integration 
to  minimize  the  impacts  on  system  acquisition.  The  PM  will  find  himself  at  the  center  of 
this  system. 


Transitioning  the  System 

A  methodology  to  accomplish  the  transition  through  the  acquisition  process  is  shown 
in  Figure  15.  To  utilize  this  model  will  require  the  creation  of  a  "critical  mass"  as  the 
strategy  for  influencing  complex  change.^  The  critical  mass  is  made  up  of  people  from 
organizations  in  and  outside  the  PMO.  They  are  individuals  who  have  legitimate  and 
informal  power  to  create  change.  The  critical  mass  looks  somewhat  atomic  in  scope  as 
opposed  to  a  standard  organizational  chart.  An  example  of  "system  critical  mass"  might 
be  Figure  1 6.5 
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Figure  15 
System  Navigation 
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The  members  provide  a  vision  for  transition  and  through  networking  and  synergy; 
implode  the  acquisition  process  to  critical  mass.  This  generates  enough  energy  and 
direction  to  overcome  resistance.  With  the  critical  mass  mode  up  of  organizations  and 
individuals  who  can  impact  system  acquisition,  there  is  ownership  in  the  implementation 
of  decisions.  This  ownership  reduces  resistance  to  change  and  reinforces  a  system  of 
networks  for  future  action. 


Returning  to  the  transition  model  in  Figure  15,  the  establishment  of  a  critical  mass, 
their  objectives  and  responsibilities  can  be  developed  by  taking  the  time  to  understand  the 
elements  of  the  model.  The  organizational  values,  mission,  goals,  objectives,  and 
responsibilities  make  up  the  substance  of  the  critical  mass  and  the  "navigational  charts" 
they  will  utilize.  This  model  has  been  used  successfully  within  organizations  who  function 
as  one  entity  and  those  who  have  come  together  to  reach  an  integrated  goal.  For  these 
reasons  the  model  could  be  utilized  at  the  PMO  level  to  chart  their  direction  and  create 
their  own  internal  critical  mass.  Or,  by  the  PMO  and  its  prime  interface  organizations, 
Figure  16,  to  organize  their  abilities  to  support  system  acquisition. 
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Figure  16 

System  Critical  Mass 
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Some  of  the  major  obstacles  to  this  method  for  managing  change  and  problem¬ 
solving  are:** 

•  Accaptance  by  key  leaders/managers  of  the  need  to  break  traditional  barriers 
and  use  non-traditional  -nethods  such  as  critical  mass. 

•  Requires  a  great  deal  of  upfront  trus*  and  honesty. 

•  Requires  a  political  strategy  to  deal  with  the  high  level  impact  and  "turf" 
issues. 

•  Development  and  utilization  of  horizontal  and  vertical  communications 
mechanisms  to  disseminate  information  quickly  in  a  rapidly  changing  environment. 

•  To  establish  an  evaluation  mechanism  to  tell  the  organization  how  well  or 
poorly  it  is  doing.  Again  honest  is  key. 

•  How  to  let  go  of  the  old  ways  while  taking  on  the  new  ideas. 

The  application  of  the  Transition  and  Planning  Model  is  best  served  by  using  an 
organizational  consultant  to  plan  and  execute  its  use.  These  consultants  ore  available  in 
all  services  and  as  independents  outside  DOD.  A  discussion  of  consultants  will  be  in  the 
section  on  resources.  The  actual  steps  in  applying  the  model  are  at  Appendix  D. 

To  expand  the  discussi<  n  on  organizational  involvement  would  be  to  propose  the 
development  of  a  "system  acquisition  network."  This  structure  would  be  made  up  of  the 
systems  critical  mass,  the  organizations  they  represent,  nd  other  organizations  that  can 
impact  acquisition,  but  are  not  a  part  of  the  critical  mass.  This  network  may  look  like 
Figure  17. 

Utilization  of  the  principles  may  improve  the  communications  and  decision-making 
process  within  a  system  acquisition  program.  This  brings  us  to  the  skill  of  process 
observation;  a  study  and  evaluation  of  the  decision-making  process. 
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Figure  !7 

Network  for  System  Acquisition 
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Process  Observation 

Thit  skill  deals  with  the  ability  to  distinguish  end  analyze  the  situation  in  two  parts: 

•  Content  -  What  is  happening. 

•  Process  -  how  it  is  happening. 

On  the  surface  the  content  issues  are  usually  visible  and  easily  identifiable. 
Examples  could  be  known  cost/schedule  variance,  design  problems,  test  results,  and 
management  decisions  to  correct  these  issues.  The  process  of  how  these  issues  occurred 
and  how  management  deals  with  them  is  generally  more  difficult  to  visualize.  The 
importance  of  this  visualization  lies  in  the  ability  to  recognize  ineffective  processes  in 
decision-making. 

At  one  time  or  another  each  of  us  have  been  involved  in  a  group  effort;  decision 
briefing,  or  staff  meeting.  And  during  these  affairs  we  have  asked  ourselves: 

•  Do  we  have  enough  information? 

•  Is  what  is  being  discussed  relevant  to  our  decision? 

•  Are  all  the  key  players  here? 

•  How  will  this  decision  affect  our  other  activities? 

Each  of  these  are  process  observations  of  the  decision-making  process.  Whether  involved 
in  a  meeting,  working  as  a  team  on  a  project,  or  individually  tackling  issues,  the  secret  is 
to  pull  away  once  in  a  while  to  analyze  the  situation  through  a  process. 

In  1971,  John  A.  Olmstead  with  the  Army  Research  Institute  developed  a  process  to 
analyze  the  way  organizations  make  decisions.'  This  same  process  con  be  applied  to  any 
systematic  situation.  Modelling  the  process  could  appear  as  shown  in  Figure  18. 

The  Information  Gathering  process  is  made  up  of  the  ways  information  is  gathered 
from  the  external  environment  or  internal  system  (refer  to  Figure  14  for  the  PM's 
system).  Here  the  availability,  medium,  accuracy  and  timeliness  ore  essential  to 
effective  information  sensing.  Next  the  sensed  information  must  be  transmitted  to  those 
elements  of  the  organization  who  must  make  decisions  or  take  actions.  Communicating 
the  gathered  information  to  those  who  need  it  in  a  timely  manner  is  important. 

With  this  information,  the  determination  of  if  an  action  will  or  will  not  be  taken 
must  be  made  for  a  conclusion  process  to  start.  Having  relevant  information  at  the 
proper  levels  of  decision-making  authority  is  necessary  for  timely  decisions.  To  analyze 
the  decisions,  the  stability  aspects  of  a  decision  must  also  be  considered.  This  requires 
decision-makers  to  recognize  the  potential  effects  of  their  decision  and  be  aware  of  the 
ability  of  their  organization  to  adjust  to  changed  conditions. 
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Once  the  decision  is  made  it  must  be  transmitted  through  a  directive,  order,  policy, 
plan  or  other  medium  to  the  organizational  elements  who  will  implement  the  decision.  To 
insure  the  decision  has  been  communicated  effectively  may  require  a  discussion  to  obtain 
clarification.  Once  communicated,  the  Implementing  process  primarily  concerns  itself 


Figure  18 

The  process  Observation  Model 
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A-ith  how  the  actions  are  io  be  executed.  Here  decision-makers  are  concerned  with  the 
effects  of  decisions  and  how  the  implementation  correlates  with  tre  original  decision. 

Finally,  an  assessment  of  the  effectiveness  of  the  organizations  actions  are 
conducted  to  provide  information  for  possible  change  to  future  decisions.  This  feedback 
process  becomes  an  input  to  the  Information  Gathering  process.  It  concerns  itself  with 
the  timeliness  and  appropriateness  of  decisions  and  actions  through  follow-up  actions. 

Follow-up  actions  are  alsc  inputs  to  Information  Gathering. 

To  enable  the  decision-maker  to  practice  this  skill,  a  list  of  process  observation 
questions  are  at  Appendix  C.  For  many  the  difficulty  is  not  in  asking  the  process 
questions,  but  in  pulling  away  from  the  content  of  what  is  happening  or  being  discussed  so 
the  process  of  how  it  is  happening  can  be  analyzed.  Techniques  to  insure  process 
observations  take  place  could  be  to  assign  the  task  to  someone  in  your  work  group  or  for 
yourself  to  break  away  and  upon  your  return,  concentrate  on  processing.  The  physical  act 
of  moving  or  sitting  back  in  your  chair  allows  you  to  withdraw  from  the  content  issues  and 
provide  you  with  a  processing  perspective.  Another  method  is  to  invite  a  consultant  in  to 
analyze  your  process  strategies  by  sitting  in  on  meetings  or  work  sessions.  At  the 
conclusion  of  the  meeting  or  at  times  you  have  agreed  to  with  the  consultant,  on 
assessment  of  how  your  group/organization  functions  could  be  provided.  A  discussion  of 
consultant  use  will  be  made  later. 

An  effective  use  of  this  skill  can  provide  insight  to  organizational  and  individual 
functioning  and  its  effectiveness.  - 


Managing  the  Innovative  and  Contextual 

If  we  view  the  system  acquisition  business  as  a  process,  then  skills  and  a  program 
management  process  are  needed  at  the  helm.  The  process  becomes  continuous  in  an 
innovative  organization  as  it  attempts  to  reoch  the  contextual  future  state  —  system 
deployment.  The  manager  in  the  innovative  organization  can  view  this  continuous  process 
as:° 


Getting  Ideas 
Blending  Ideas 
Funding 


Transition  the  program 


System 


Organization(s) 


•  Managing  program  interfaces 

An  innovative  contextual  program  will  also  require  the  PM  to  rapidly  transition  in 
time  between  the  past,  present,  and  future  of  Figure  19. 
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Lessons 

Learned 


Where  are 
we  NOW? 


Where  CAN 
we  be? 


I - X - 1 

Systems  Systems  Systems 

Past  Present  Future 


Figure  19 
Systems  Time  Line 


The  PM  must  spend  only  that  amount  of  time  it  takes  to  understand  the  past  and  confirm 
the  present  before  regaining  his/her  position  in  the  future.  As  the  PM  makes  this 
transition  to  the  future,  the  visualization  of  "what  can  be"  becomes  the  substance  for 
navigating  the  program.  This  is  a  contextual  view  of  program  management.  This  implies 
that  our  PM's  must  operate  from  a  different  point  in  time  --  System  Future. 

PLANNING.  If  we  combine  the  ideas  earlier  of  strategic  planning  with  contextual 
visioning,  the  PM  can  then  visualize  the  completed  acquisition  strategy  before  the  needed 
actions  are  identified.  In  other  words,  the  PM  sees  "what  can  the  system  be"  before 
he/she  identifies  how  they  will  get  there.  Systemically,  the  planning  process  can  then  be: 

OBJECTIVES  What  do  we  want  it  to  be? 

METHODS  Alternatives  to  how  we  can  get  there. 

RESOURCES  What  we  need  to  get  there. 

A  matrix  can  now  be  developed  for  planning,  implementation,  and  evaluation. 


PLANNING 

IMPLEMENTING 

EVALUATING 

OBJECTIVES 

What  do  we 

Reach  objectives - ► 

Did  we  meet  our 

want? 

objectives? 

What  is 

Were  the  most 

METHODS 

the  best 

Apply  method. 

effective  methods 

method? 

used? 

What  j 

Were  the  right 

RESOURCES  J 

,  resources  s 

Obtain  resources.  ^ 

,  resources  selected 

ore  needed? 

and  cvai  table? 

Figure  20 

Planning,  Implementing  and  Evaluating  Matrix 


CONTEXT .  With  an  understanding  of  strategic  planning,  the  idea  of  being 
contextual  or  managing  context  needs  expansion.  Context  is  the  bounding  of  a  situation 
where  content  becomes  what  is  inside  that  boundary.^  If  our  PM  is  into  painting,  the  edge 
of  a  mat  is  the  context  and  the  picture  within  the  mat  is  the  content.  And  since  PM's  deal 
in  knowns,  know-unknowns,  and  unknown-unknowns,  then  the  following  is  valid: 


CONTENT  -  Knowns  and  Known-Unknowns 
CONTEXT  s  Unknown-Unknowns 


If  the  PM  locks  into  the  content  issues,  he/she  will  be  unprepared  to  handle  the 
"unk-unk's"  when  they  become  known.  Therefore,  how  the  PM  navigates  the  program  can 
be  an  indicator  of  how  contextual  his/her  scope  is  for  the  system. 

If  we  link  context  with  process  observation,  we  can  see  how  a  PM  can  be  contextual 
in  the  management  of  the  program.  It  can  be  evident  in  the  questions,  actions,  or 
behavior  of  the  PM.  Does  the  PM  concentrate  on  what  is  known  or  is  he/she  always 
placing  themselves  in  the  system  future?  An  example  of  context  could  be  Figure  21.  *0 


(A) 


(B) 


Figure  21 
Context  for  Two 


The  lines  in  (A)  are  equal  in  length;  this  is  one  context.  In  (B)  they  are  also  equal, 
but  presented  in  a  different  context  and  now  (A)  and  (B)  are  not  visualized  as  equal.  For 
the  PM,  if  he/she  asks  the  right  questions  so  that  the  boundary  does  not  limit  the  answers 
to  the  knowns  or  known-unknowns,  then  the  program's  scope  will  be  prepared  to  handle  the 
unk-unk'r.  This  management  behavior  expands  the  context  of  the  program.  • 

Another  example  of  context  is  how  the  PMO  staff  are  utilized.  Many  are  used  as 
"problem-solvers,  trouble-shooters,  fire-fighters,  etc."  They  pride  themselves  on  saving 
something  or  reducing  risk  because  risk  equals  a  problem.  With  this  responsibility  comes 
two  dilemmas: 

1.  Self-Fulfilling  Prophecy  There  is/will  be  a  problem.  9 

2.  Problem  Ownership  If  it  is  solved,  my  job  is  finished. 
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These  dilemmas  have  been  seen  in  some  engineering  and  design  approaches  where  a 
hardware  problem  given  unlimited  time  and  money  con  become  a  cost  and  schedule 
problem.  Generally,  this  is  propagated  by  our  "cnrrot-stick"  reward  system  built  on  the 
notion  that  "if  you  do  better  you  will  get  more."liBy  changing  the  context  of  how  our 
people  ore  managed,  the  important  factors  become  the  mission,  goals/objectives  and 
acquisition  strategy.  And  doing  your  job  according  to  these  factors  becomes  important 
and  rewarded.  If  this  context  is  used,  our  engineer  is  not  contributing  to  the  program 
because  his/her  efforts  do  not  compliment  our  objectives  and  strategy. 

One  last  example  of  improper  focus  in  context  is  the  current  utilization  of  quality 
assurance  programs.  The  context  being  used  reinforces  quality  assurance  versus  quality 
work  up  front.  To  some  degree  this  too  can  become  self-fulfilling.  With  a  context 
directed  towards  QA,  the  results  are  a  large  QA  team,  high  dollar  costs,  and  a  workforce 
that  relies  heavily  on  what  the  QA  team  finds.  By  changing  the  context  to  quality  work 
up  front,  the  desire  is  to  "do  it  right  the  first  time,"  reducing  the  QA  requirements. 

INNOVATION  AND  CONTEXT.  With  an  understanding  of  context  and  defining 
innovative  as  "coupled  knowledge,"  the  acquisition  life  cycle  can  take  another  form; 
F  igure  22. 1 


•» 


SUPPORT 


RESOURCES 


I  DO  MY  BEST 
TO  PORTRAY  A 
WIDE  VISION 


Figure  22 

Innovative  and  Contextual 
Acquisition  Life  Cycle 


The  PM  takes  an  “open"  view  of  acquisition  from  the  system  future  and  establishes 
an  innovative  organization  by  integrating  the  skills  and  knowledge  of  his/her  staff.  This 
helps  the  PM  out  front  as  the  navigator  managing  the  acquisition  process  and  the  staff 
moving  the  system  through  this  process. 
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FUTURE  TECHNOLOGIES  FOR  PROGRAM  MANAGEMENT 

Where  Are  We  Headed? 

The  Program  Manager  of  today  and  most  certainly  tomorrow  is  going  to  be  a 
"systems  leader"  with  the  challenge  of  managing  their  level  of  Force  Modernisation J 3 
The  PM's  background  and  responsibilities  will  thrust  him/her  to  the  forefront  of  this 
defense  transitioning.  With  our  technology  and  that  of  the  Threat  changing  rapidly,  the 
PM's  sensing  and  communicating  skills  will  have  to  be  continuously  enhanced.  Coupling 
the  pace  of  technology  with  the  complexity  of  the  PM's  integration  responsibilities,  new 
methodologies  are  needed  for  program  management. 

The  DSMC  Interface 

Many  of  the  questionnaire  respondents  and  several  PMO  folks  I  have  talked  with  are 
looking  for  management  techniques  to  assist  in  their  situations.  There  are  some  activities 
on-going  at  DSMC  and  I  will  recommend  two  more. 

PROGRAM  SUCCESS.  There  are  studies  in  progress  on  analyzing  success  in  program 
management  and  to  develop  the  traits  and  causes  of  success.  Once  reduced  and  published 
to  the  program  management  community,  this  data  could  assist  PM's  in  acquisition  strategy 
development  and  program  management. 

PMSS.  The  Research  Department  is  developing  a  computer  assisted  decision-making  tool 
called  PMSS,  Program  Managers  Support  System. I ^  This  system  will  assist  the  PM/PMO 
in  the  assimilation  of  program  data  and  allow  them  to  develop  decision  alternatives  and 
study  their  impacts.  It  will  not  make  the  decision,  but  will  help  to  determine  "what  :f" 
parameters.  Figure  23  models  the  systems  implementation.  15 


Figure  23 

PMSS  Implementation  Approach 
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The  process  will  require  identification  of  the  PM/PMO's  internal  and  external 
information  requirements  for  program  management.  These  will  be  the  PMSS  inputs.  The 
PM/PMO's  will  also  identify  the  information  and  actions  to  be  supplied  outside  the  PMO. 
These  will  become  the  PMO  outputs  (see  Figure  14,  PM's  Open  System).  By  understanding 
the  interfaces  of  the  program: 

•  What  are  the  interfaces? 

•  Who  is  involved? 

•  What  are  the  boundary  factors  reducing  the  effectiveness  of  the  inter¬ 
face? 

The  PMO  can  then  utilize  PMSS  along  with  their  "gut"  feeling  and  experiential  judgment 
base  to  make  decisions.  In  this  process  of  combining  Management  Science,  Operations 
Research,  Behavioral  Science,  and  Computer  Science  technology  as  part  of  the  trans¬ 
formation  process  (Figure  14),  the  outputs  could  have  a  broader  context,  and  more 
accurate  and  timely. 

At  this  time  DSMC  plans  to  produce  a  I PMSS  Guidebook,  configurations  and  spec's, 
and  a  software  package  for  implementation. '  ° 

There  are  many  more  activities  at  DSMC,  many  even  as  a  student  I  probably  haven't 
heard  about.  The  Policy  and  Organization  Management  Department  (POMD)  has  an  active 
course  of  instruction  in  Executive  Communications  and  Human  Resource  Management. 
They  also  provide  a  selective  consultant  service  to  OSD  and  the  services  along  with  their 
research  work,  to  assist  organizations  involved  in  systems  acquisition.  DSMC's  most 
active  source  of  current  acquisition  issues  are  published  in  Concepts  and  PM  Magazine. 
The  Research  Department  devotes  itself  to  the  identification  of  these  issues  and  sources 
or  methodology  for  solving  or  assisting  the  acquisition  community  in  resolving  key  issues. 
Since  the  purpose  of  my  research  does  not  include  a  "tour"  of  DSMC  facilities,  I  will  cut 
the  DSMC  Interface  discussion  at  this  point.  More  assistance  resources  will  be  discussed 
under  the  section  on  resources. 


RECOMMENDATIONS  AND  CONCLUSION 


First,  i  hope  my  research  can  provide  some  insight  or  validate  your  thoughts  on  how 
the  system,  organizations,  and  people  interface.  But,  there  are  also  a  few  ideas  that  have 
come  from  the  interaction  and  research  in  the  development  of  this  paper. 

The  "Think  Piece" 


DSMC  has  started  a  moderate  level  research  effort  for  PMC  students  to  use  as  a 
learning  medium.  In  PMC  82-2,  the  initiatives  of  Deputy  Secretary  Carlucci’s  Acquisition 
Improvement  Program  (AIP)  were  divided  up  for  student  comment.  This  technique  served 
several  purposes. 

1.  To  enable  each  student  to  gain  some  additional  insight  into  the  AIP  and  how  it 
is  envisioned. 

2.  Provided  a  reality  check  for  AIP  since  many  students  are  representing 
programs  of  ail  services. 

3.  Hopefully  spawned  many  new  advocates  for  acquisition  improvement. 

By  reviewing  the  backgrounds  of  the  students,  it  becomes  evident  that  there  is  an 
excellent  potential  to  gain  innovative  ideas  from  their  broad  knowledge  and  experience 
base.  This  base  could  be  tapped  through  the  "Think  Piece"  program  much  the  same  way  a 
prolific  Colonel  once  prophesized. 

Colonel  Mike  Malone,  US  Army  (Ret),  told  a  story  of  a  fictitious  instructor  at  the 
Army's  Command  and  General  Staff  College  who  took  some  students  and  had  them  study 
the  C^l  failures  of  a  large  DoD  exercise.*  '  He  limited  each  to  one  paragraph  per  failure, 
10  per  student.  After  a  few  weeks  they  met  to  prioritize  and  categorize  each  failure.  He 
then  had  them  look  to  technology  and  see  what  was  available  today  that  could  have 
benefited  each  category.  Finally,  the  fictitious  instructor  had  the  students  summarize 
some  new  methodologies  and  skills  to  better  the  C^l  issue. 

Although  this  concept  was  one  man's  imagination,  its  implementation  is  being 
studied  at  CGSC  and  fhe  Army  War  College.  This  same  principle  could  be  utilized  at  the 
SX  group  level  to  broaden  the  context  of  current  system  acquisition  issues.  This  could 
expand  the  information  base  of  the  Research  Department  and  provide  a  methodology  for 
sharing  knowledge  and  experiences  among  students  and  the  acquisition  community. 

System  Acquisition  Networking 

Today  in  DoD  and  industry,  technology  and  information  are  expanding  like  scientists 
perceive  the  universe  expands,  a  concept  ttv’t  is  becoming  more  and  more  utilized  to 
keep  up  with  the  pace  is  computer  network  conferencing.  By  linking  various  organizations 
concerned  with  common  issues,  the  expertises  of  many  are  brought  to  bee.  on  the  subject. 
As  success  is  gained,  it  is  shared  with  others.  As  "what  can  it  be"  questions  are  posed  to 
the  net,  new  unknowns  are  uncovered,  broadening  the  issue  conte  <t. 
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As  I  discussed  earlier,  tne  power  of  linking  the  'critical  mass"  of  various  organiza¬ 
tions  in  system  acquisition,  the  potential  for  directed  energy  at  current  issues  is  vast.  To 
link  technology  to  critical  mass  would  require  the  following: 

•  A  voluntary  commitment  by  those  linked  to  the  network  based  on  the  desire  to 
contribute  to  improving  the  system  acquisition  process. 

•  Honesty,  openness,  trust  and  candor  among  network  members. 

•  An  inexpensive  terminal  and  telephone  connection  with  hard  copy  capability. 

•  A  computer  conferencing  program  for  members  to  tie  into  at  their  discretion. 
The  Defense  Systems  Management  could  sponsor  this  activity  linking  both  DoD,  the 

industrial  base,  and  other  system  acquisition  agencies.  Not  only  would  this  serve  as  a 
medium  to  put  forth  concepts  or  issues  for  comment,  but  could  also  draw  the  members 
closer  together  in  resolving  some  of  the  problems  confronting  the  acquisition  process. 
Figure  24  presents  an  example  of  a  system  acquisition  network. 


OPT  EV  FOR 


Figure  24 

System  Acquisition  Networking 


This  network  concept  has  been  functioning  very  successfully  in  the  US  Army  through 
the  Army  War  College  at  Carlisle  Barracks.  It  is  known  as  the  "Delta  Force"  and  is  hiahly 
supported  by  the  Army’s  Chief  of  Staff.  Appendix  F  contains  the  Delta  Force  concept.  *8 


Other  Recommendations 

•  Provide  instructions  on  process  observation  to  PMC  students  and  include  its 
practice  as  a  part  of  the  System  Exercise  (SX). 

•  Broaden  the  scope  of  the  research  on  interface  and  context  to  include  the 
concept  of  Brain  Dominance.  This  could  provide  data  on  how  to  utilize  left 
brain  right  brain,  and  double-dominant  individuals  when  managing  interfaces. 

•  Utilize  the  Multi-Dimensional  Program  Management  Model  to  portray  inter¬ 
face  and  expand  the  methodology  section  to  include: 

How  to  pick  and  assign  PMO  personnel  to  assist  the  PM  in  handling 
interface  situations. 

2.  How  to  train  PMO  personnel  to  recognize  boundary  densities  and  their 
factors  and  to  manage  them. 


Conclusions 


The  Multi-Dimensional  Program  Management  Model  is  a  valid  representation  of  the 
complex  environment  of  the  Program  Manager  and  the  Program  Management  Office. 
Understanding  its  principles  of  interface  and  boundaries  could  provide  insight  on  how  to 
enhance  integration  by  recognizing  where  to  place  the  most  effort.  Again,  the 
methodologies  and  recommendations  were  not  meant  to  provide  a  cookbook  solution  to 
integration  management.  But,  to  provide  some  indication  of  what  con  be  utilized  if 
pursued  to  full  understanding  or  consultant  assistance  is  employed. 


PHILIP  E.  HAMILTON 
CPT.  USA 
DSMC,  PMC  82-2 
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APPENDIX  A 

ORIGINAL  CONCEPT  PAPER/QUESTIONNAIRE 
INCLOSURE  I 

In  this  concept  paper,  the  Multi-Dimensional  Program  Management  Model  will  he 
developed  to  establish  a  common  understanding  before  proceeding  to  Inclosure  2,  the 
questionnaire.  This  development  will  be  in  steps. 

1.  Depicting  the  internal  interface  within  organizations,  personnel,  and  the  sys¬ 
tem/product  domains. 

2.  Taking  a  more  macro  view  of  the  domains  to  show  interface  in  depth. 

3.  Describing  interface  boundary  factors  and  how  they  may  hinder  effective  inter¬ 
action. 

k.  Combining  the  above  steps  with  the  system  acquisition  life  cycle  to  obtain  the  M- 
DPM  Model. 


THE  MULTI-DIMENSIONAL 
PROGRAM  MANAGEMENT  MODEL 

A  proper  model  must  first  be  developed  so  that  key  interfaces  can  be  studied  before 
turning  attention  to  interface  management  methodologies.  Below  we  can  view  different 
acquisition  organizations  as  they  are  integrated  by  the  Program  Management  Office 
(PMO). 


Figure  I 

Organizational  Interaction 


!t  is  a  role  of  the  Program  Manager  (PM)  to  successfully  integrate  the  functions  of  these 
organizations  as  they  apply  to  the  acquisition  process.  This  same  model  can  be  used  when 
describing  the  system/product  and  the  personnel  involved  in  system  acquisition  and  life 
cycle  management. 


Figure  2 
System/Product 


Therefore,  Figures  1-3  imply  there  are  multiple  interfaces  for  the  PM  and  PMO  to 
continuously  manage  in  the  domains  of  product,  organizations,  and  personnel. 

Although  we  have  only  depicted  three  areas  in  each  domain,  acquisition  reality  tells  us 
there  could  be  many  levels  within  each  domain.  If  we  list  several  areas  under  each 
domain  and  take  a  more  macro  view,  the  model  now  takes  on  much  more  depth.  Figure  4 
illustrates  the  interaction  of  the  major  domains  and  the  resultont  interfaces  in  depth. 
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At  this  stage,  the  combinations  of  interfaces  between  product,  organization,  and 
personnel  are  of  a  large  magnitude.  It  takes  personnel  to  make  organizations  who  interact 
to  acquire  systems  which  involve  subsystems,  and  are  made  for  people's  use;  etc...  Since 


interfaces  are  multiple  and  in-depth,  it  will  take  multiple  strategies  to  manage  this 
interaction.  This  will  require  a  description  of  an  interface  itself. 

For  this  example  we  will  take  two  groups  from  the  organizational  domain,  the  contractor 
and  the  user.  On  most  of  our  systems,  the  user  and  contractor  must  interact  from 
concept  exploration  through  production  and  deployment.  During  interface,  boundaries 
may  develop  hindering  the  effectiveness  of  the  interaction.  Visually  this  may  look  like 
Figure  5. 


BOUNDHY 

DENSITY 


Figure  5 

Interlace  Boundary  Representation 


The  dotted  lines  represent  the  boundary  hindering  effective  interaction  by  varying 
degrees,  dependent  on  the  factors  which  contribute  to  increasing  the  density  of  the 
boundary.  The  boundary  factors  affecting  density  are: 

•  Organizational  values 

•  Biases 

•  Perspectives 

•  Organizational  goals 

•  Expectations 

•  Needs  and  desir.  > 

•  Organizational  behavior 

•  Politics 

•  Regulations  and  Directives 

•  Organizational  structure 

•  Communications 

•  Others 
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The  density  itself  implies  the  difficulty  in  achieving  effective  interaction.  It  is  this 
boundary  density  the  PM  is  tasked  to  reduce,  hopefully  to  the  point  that  it  no  longer 
exists—total  effective  interface  management  between  user  and  contractor.  This  would 
indicate  a  purpose  to  the  research  study.  Through  modeling,  an  understanding  of  the 
Program  Manager's  responsibilities  in  the  integration  and  interface  management  could 
lead  to  identification  and  analysis  of  management  methodologies  to  be  used  by  a  PM. 

As  a  further  step  in  identifying  boundaries,  while  referring  to  Figure  U  again,  the 
personnel  and  system  domains  might  reflect  these  potential  boundary  factors: 


•PERSONNEL 

•  Individual  Values 

•  Biases 

•  Perspectives 

•  Individual  Behavior 

•  Needs  and  Desires 

•  Expectations 

•  Communications 

•  Others 


SYSTEMS/PRODUCT 

•  Technology 

•  The  Threat 

•  Available  Resources 

•  Authorized  $$$ 

•  Appropriated  $$$ 

•  Design 

•  Engineering 

•  Manufacturing 

•  Contracts 

•  T&E 

•  Others 


•Note  how  personnel  and  organizational  boundary  factors  are  similar.  This  is  because 
they  are  people  issues  where  the  system  factors  are  non-people. 

As  a  last  step  in  portraying  the  magnitude  of  the  interface  issue,  we  can  show  the 
dimensionality  by  applying  interface  in  depth  (Figure  4)  to  the  system  acquisition  life 
cycle.  This  results  in  the  Multi-Dimensional  Program  Management  Model,  Figure  6. 

If  this  depicts  an  accurate  view  of  the  magnitude  and  dimensionality  of  the  PM's 
integration  and  interface  management  issues,  the  next  step  will  be  to  identify  and  analyze 
methodologies  and  skills  such  as: 

•  Goal  integration 

•  Role  clarification 

•  Transition  management 

...just  to  name  a  few.  Then  to  provide  a  list  of  potential  resources  from  which  the  PM 
and/or  his  PMO  could  obtain  the  necessary  skills,  knowledge,  or  assistance. 

But  first  the  model  concept  must  be  refined  and  validated.  This  leads  us  to  the 
questionnaire. 


PROCEED  TO  INCLOSURE  2 
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FIGURE  6.  THE  MULT I-DIHENT ION AL  PROGRAM  MANAGEMENT  MODEL 
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INCLOSURE  2 


With  Inclosure  1  as  a  basis  for  common  understanding  of  the  M-DPM  Model,  the  following 
questions  are  asked  to  gain  clarity  and  your  views  on  the  subject  matter. 


DEMOGRAPHICS 

i.  PM's  Service: 

Army 

Air  Force  Navy 

_ Marine  Corp: 

2.  Joint  Acquisition: 

Yes 

No 

3.  Major  Acquisition: 

Yes 

No 

(DODD  5000.1) 

4.  Management  Structure  of  PMO: 

_ Functional _ Product _ Matrix 

5.  Where  is  your  system  in  the  acquisition  process? 

_ Concept  Exploration 

_ Development  and  Validation 

_ Full  Scale  Development 

_ Production/Deployment 

6.  First  unit  cost  or  estimate:  _ 

7.  How  long  has  PMO  been  established?  _ 

8.  How  long  have  you  been  the  PM?  _ 

9.  Size  of  PMO:  _ personnel 

10.  Percentage  of  military  in  PMO:  _ %  military 

11.  Average  turnover  in  PMO  during  one  year 
_ %  turnover 

The  following  questions  are  directed  at  the  Multi-Dimensional  Model  and  how  it  might 
relate  to  your  situation. 

1.  Couid  you  see  your  PMO  in  this  model? 

Very  little  (1)  (2)  (3)  (4)  (5)  Very  much 

similarity  like  ours 


How  effective  is  the  interface  represented? 


Ineffective  Effective 

Personnel  (1)  (2)  (3)  (4)  (5) 

Organizations  (1)  (2)  (3)  (4)  (5) 

System  (1)  (2)  (3)  (4)  (5) 

How  effective  are  the  boundaries  explained? 

Ineffective  Effective 

Personnel  (1)  (2)  (3)  (4)  (5) 

Organizations  (I)  (2)  (3)  (4)  (5) 

System  (1)  (2)  (3)  (4)  (5) 

Would  this  model,  an  in-depth  explanation,  and  a  discussion  of  methodologies  to 
breakdown  boundaries  be  useful  to  PMO's? 

Not  very  (1)  (2)  (3)  (4)  (5)  Very 

useful  useful 

What  changes  would  you  make  to  the  Multi-Dimensional  Model? 


Is  there  general  agreement  with  the  goal  and  objectives  in  your  program? 

Very  Little  Strong  Agreement 

a.  Among  Personnel  (1)  (2)  (3)  (4)  (5) 

b.  Among  Organizations  (1)  (2)  (3)  (4)  (5) 


What  other  boundary  factors  exist  for  you? 
Personnel: 


Organizations: 

System/Product: 

Are  operational  territories  and  responsibilities  clearly  understood  in  your  program? 

Most  Unclear  All  Are  Clear 
Personnel  (1)  (2)  (3)  (4)  (5) 

Organizations  (1)  (2)  (3)  (4)  (5) 

Referring  to  Figure  4  (Inclosure  1),  which  elements  cause  the  most  concern  in 
integration  and  interface  management? 


PERSONNEL 


RGANIZATIONS 


SYSTEM 


(1)  ( 

[2)  C 

3)  C 

[4)  (< 

D  (1) 

2)  (2) 

5)  (3) 

»)  (4) 

,5)  (. 

>)  (5) 

What  are  the  most  important  skills/ knowledge  for  a  PM  to  understand  and  use? 

(1  -  Important,  2  -  Somewhat,  3  -  Not  Very  Important) 

_ Business  Management 

_ Design 

_ Leadership 

_ _ __  Group  Dynamics 

_ Communications 

_ _  Systems 

_ Behavioral  Science 

_ Engineering 

_ Self-Awareness 

_ Counseling 

_ Process  Observation  (how  things  happen) 

_ Creative  Thinking 

_  Acquisition  Process 
Others  not  listed: 
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11.  What  other  comments  would  you  like  to  add  based  on  your  experiences? 


Thank  you  for  your  openness  and  sincerity  in  helping  me  with  this  research.  1  wish  to 
again  mention  that  1  will  personally  handle  all  data  in  a  confidential  and  anonymous 
manner. 

I  do/do  not  desire  a  copy  of  the  study. 


Return  to  Phil  Hamilton's  student  box  inlT  15  September  1982. 


Thank  You! 


APPENDIX  B 


QUESTIONNAIRE  DATA  REDUCTION 


The  data  has  been  broken  out  into: 

•  Section  A  which  includes  selected  demographic  information. 

•  Section  B  with  numerical  and  single  answer  information  on  the  model  and  the 
respondent's  program. 

•  Section  C  comprising  structured  comments  on  the  model  and  program  manage¬ 
ment  in  general. 

•  Section  D,  a  discussion  of  selected  data. 

It  must  be  noted  that  some  respondants  elected  to  not  answer  some  questions. 


SECTION  A 


PM's 

ERC 

DSMC 

Faculty 

PMC 

Students 

• 

Number  of  Respondents 

16  of  21 

9  of  29 

18  of  24 

14  of  26 

• 

Service 

Army 

7 

3 

6 

2 

Air  Force 

6 

4 

5 

9 

Navy/MC 

3 

1 

6 

3 

• 

Involved  in  a  Joint  Program 

7 

3 

9 

3 

• 

Involved  in  Major  System  Acquisition 

15 

5 

12 

9 

• 

Management  Structure  of  PMO 

Functional 

2 

3 

5 

4 

Product 

2 

3 

5 

4 

Matrix 

12 

2 

9 

3 

•  Which  Phase  of  Acquisition 


All  D/V  to  P/D  All 


All 


-  PM's  were  found  to  be  primarily  in  FSD  and  P/0 

-  ERC  were  most  in  P/D 

-  Faculty  were  mostly  in  FSD 

-  Students  were  generally  in  FSD  and  P/D 

•  Size  of  PMO 


Highest 

AA5 

A50 

250 

A  50 

Lowest 

9 

33 

5 

2 

Average 

137 

IA5 

A6 

100 

•  Percentage  of  Military  in  PMO 

31 

3A 

33 

A5 

•  Percentage  of  Annual  Personnel  Turnover 

16 

15 

26 

17 

Section  B 

Where  the  answers  to  questions  are  numerical,  refer  to  the  questionnaire  at  Appendix  A 
for  the  qualifier.  Generally,  a  I  or  2  implied  low  or  somewhat  negative  answer  and  A  or  5 
is  high  or  positive. 

1 .  Could  you  see  your  PMO  in  this  model? 

PM’s:  A 2  ERC:  3.5  Faculty.  3.A  Students:  3.6 

2.  How  effective  is  the  interface  represented? 


PM's 

ERC 

Faculty 

PMC 

Personnel? 

3.8 

3.1 

3.2 

3.A 

Organizations: 

3.7 

2.9 

3.3 

3.A 

Systems: 

A.O 

3.1 

3.3 

3.A 

How  effective  are  the  boundries  explained? 

PM's 

ERC 

Faculty 

PMC 

Personnel: 

A.3 

3.0 

2.5 

3.A 

Organizations: 

A.A 

2.6 

2.8 

3.S 

Systems: 

A.A 

2.8 

2.8 

3.3 
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4-  Would  this  model,  an  in-depth  explanation,  and  a  discussion  of  methodologies  to 
breakdown  boundries  be  useful  to  PMO's? 

PM'ss  3.3  ERCs  2.3  Faculty:  3.2  PMC:  3.8 

5.  See  Comments. 

6.  is  there  general  agreement  with  the  goal  and  objectives  in  your  program? 


PM*s 

ERC 

Faculty 

PMC 

Among  Personnel: 

4.2 

3.6 

3.1 

3.7 

Among  Organizations: 

3.9 

2.5 

2.8 

3.8 

7.  See  comments. 

8.  Are  operational  territories  and  responsibilities  clearly  understood  in  your  program? 


PM's 

ERC 

Faculty 

PMC 

Among  Personnel: 

4.0 

3.7 

3.7 

3.2 

Among  Organizations: 

3.9 

3.1 

3.4 

3.4 

|  9.  Which  elements  cause  the  most  concern  in  integration  and  interface  management? 

P 


Personnel 

Organizations 

Systems 

PM's: 

(1) 

Individuals 

Contractor 

Resources 

(2) 

Civilians 

OSD/Congress 

Support  Equipment 

(3) 

Work  Groups 

Users 

Sof  tware/Documen  tat  i  on 

ERC: 

(1) 

Individuals 

Users 

ILS 

(2) 

Work  Groups 

OSD/ Congress 

Resources 

(3) 

User  Rep's 

Contractor 

Documentation 

Faculty: 

(1) 

Individuals 

Higher  HQ's 

Resources 

(2) 

Civilians 

Contractor 

Hardware 

(3) 

Work  Groups 

Users 

Software 

PMC: 

(1) 

Work  Groups 

Congress 

Software 

(2) 

Individuals 

Contractor 

ILS 

(3) 

Civilians 

OSD 

Documentation 

<  • 

0-3 


r 


n 


f 


9 


V 


I 


1 


10.  What  are  the  most  important  skills/knowledge  for  a  PM  to  understand  and  use? 
(I  -  important,  2  -  Somewhat,  3  -  Not  Very  Important) 


PM's 

ERC 

Foculty 

PMC 

Business  Management 

l.l 

l.l 

1.3 

1.2 

Design 

2.2 

2.1 

2.0 

2.0 

Leadership 

1.0 

1.0 

1.2 

1.0 

Group  Dynamics 

1.2 

1.6 

1.7 

1.5 

Communications 

1.0 

i.2 

l.l 

l.l 

Systems 

1.6 

2.1 

1.7 

1.7 

Behavioral  Science 

1.7 

1.7 

1.8 

2.0 

Engineering 

1.9 

2.0 

1.8 

2.1 

Self-Awareness 

1.7 

1.0 

1.6 

1.8 

Counseling 

1.7 

1.9 

2.2 

2.1 

Process  Observation 

1.3 

1.7 

1.5 

1.9 

Creative  Thinking 

1.2 

1.8 

1.6 

1.7 

Acquisition  Process 

1.3 

1.2 

1.4 

1.4 

Additional  skills  and  knowledge  recommended  by  respondents 

•  Problem-Solving 

•  Politics 

«  User  Needs  Assessment 

•  Threat  Analysis/Capabilities 

•  Delegation 

•  ILS 

•  Manpower 

•  Test  and  Evaluation 

•  Tech  Management 

•  Memory 
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SOLICITED  COMMENTS  TO  SPECIFIC  QUESTIONS 


Question  5:  Whot  changes  would  you  make  to  the  Multi-I  )imensional  Model? 

Program  Manager  Comments: 

•  Change  personnel  to  resources:  funds,  personnel,  facilities,  etc. 

•  Can't  argue  with  model,  but  seems  basic 

•  Include  the  development  community 

•  Add  more  factors  and  degrees 

•  Unknowns 

•  Changing  personalities  -  decision  makers 

•  Show  me  how  everything  is  interacting  with  everything  else  at  the  same  time 

•  Add  international  interactions 

•  Users  only  interface  with  Congress  when  submitting  testimony  support 
requirements 

•  Include  Small  Business  -  These  set  aside  sometimes  create  boundry  factors  for 
Kr's 

•  Expand  personnel  boundries  to  include  minorities  and  women  -  management 
challenges 

i  3 

•  Add  P  I  to  keep  up  with  threat.  Development  phase  of  P  I  (6.2,  6.3A) 
generady  parallels  FSD  and  P/D  (6.3B,  6.4) 

•  Correct  course  -  expand  it 

Executive  Refresher  Course  Comments: 

•  Why  not  informal  vs.  formal  -  Good  ol'  boy  networks  are  most  important 

•  Add  contract  administration  -  CAO 

•  Add  flexibility  between  phases. 


DSMC  Faculty  Comments: 

•  Show  complexity  of  interface  issues  and  how  composition  changes  throughout 
life  cycle 

•  Add  more  depth  to  discussions 

•  How  are  work  groups  different  from  organizations? 

•  Using  hierarchy  of  systems  model,  personnel  and  organizations  are  the  same, 
not  discrete  domains 

•  Different  organizations  require  different  emphasis  depending  on  life  cycle 
phase 

•  Inconsistent  hierarchy  between  personnel  and  organizations 

•  Add  more  to  discussions 

•  Expand  and  show  how  PM  could  effectively  apply  the  model 

•  Show  more  examples 

•  Need  methodologies  to  break  down  boundries 

PMC  Student  Comments: 

•  Add  FMS/State  Department 

•  Add  logistics  and  training 

•  Show  how  O/S/P  is  continuous  throughout  acquisition  and  alwoys  changing 

•  ncreasc-  emphasis  on  interface  -  too  important 

•  Develop  techniques  and  methodologies  to  use 

•  Expand 

•  How  do  we  break  down  the  boundries? 

»  Interfaces  are  variable 

•  Distinguish  between  near-mid-long  term  activities 

•  Conrder  the  changes  in  the  interface  intensity  (density) 
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Question  7:  What  other  boundry  factors  exist  for  you? 

Personnel  Boundry  Factors: 

Program  Manager  Comments: 

•  "30  minute  experts"  -  To  be  briefed  means  you  are  now  an  expert  with 
suggestions 

•  Personnel  resources 

•  "This  is  the  way  we  do  it  in  my  service" 

•  Lack  of  training 

Executive  Refresher  Course  Comments: 

•  Freeze  and  hiring  restrictions 

•  Personnel  goals 

OSMC  Faculty  Comments: 

•  Individual  goals 

•  Personnel  regulations  and  directives 

•  Individual  guidance  and  directives 

•  Lack  of  mobility  in  civilian  work  force 

•  Lack  of  accountability 

•  Lack  of  rewardability 

PMC  Student  Comments: 

•  Management  styles 

•  Personal  abilities 

•  Evaluation  and  promotion  policites 

•  "Tire  kicking"  Visitors 

•  Unproductive  personnel 
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Organizational  Boundry  Factors:  p  - 

Program  Manager  Comments: 

•  Different  Kr's/subs 

•  Layered  organizations  -  can  only  say  no  p  . 

•  Perception  of  threat  by  combat  developer  vs.  material  developer 

•  Behind  the  scenes  support  -  upfront  everything  looks  rosey  (don't  want  to  be 
embarrassed) 

•  Not  invented  here  -  Don't  use  it  ^ 

;  : 

•  Lack  of  ability  to  compromise  -  Example  -  User  won't  give  up  cost  driver 
because  his  HHQ  might  say  he  is  stupid 


Executive  Refresher  Course  Comments: 

•  Production  facilities 

•  OSD  vs.  Army 

•  Foreign  alternative  systems 

•  Media  hostility 

•  CAO 

•  Supporting  agencies  -  Energy  Department 
DSMC  Faculty  Comments: 

•  Procedures  that  limit  latitude  of  functional  managers  to  support  program 

#>  Personnel  resources 

PMC  Student  Comments: 

•  Manpower  levels  (actual  vs.  need) 

•  FMS  countries  and  their  values/culture 

•  MOA's 
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•  Politics 

•  Operational  procedures 

•  Labs 

•  llities 

•  Independent  testers 

•  Suburban  supporters 

•  Development  and  training  commands 

•  JCS 

•  DIA 

•  Too  rigid  procedures 

•  Joint  service  programs 

•  NASA 

•  DARPA 

System  Boundry  Factors: 

Program  Manager  Comments: 

•  PIP'S 

•  Multiple  sources 

•  Priorities 

Executive  Refresher  Course  Comments: 

•  $$$ 

•  ILS 

DSMC  Faculty  Comments: 

•  Schedules 

•  Time,  $$,  resources 


•  Need/threat 
PMC  Student  Comments: 

•  SPEC's/STD's 

•  Quality 

•  Parallel  development/concurrency 

•  Hi  Tech 

•  State-of-the-art 

•  Technology  demonstrators  vs.  prototypes 

•  Maintenance 

•  Training 


Question  1 1:  What  other  comments  would  you  like  to  add  based  on  your  experiences? 

Program  Manager  Comments: 

•  In  real  world,  it's  dynamic. 

•  Truth  is  few  organizations  or  personnel  are  results  oriented  outside  the  PMO. 

•  PMO  is  still  more  complicated. 

•  Too  many  decision  makers  in  the  act  above  PM  -  PM  makes  minor  ones. 

•  PM  performance  proportional  to  Kr's  -  We  have  to  get  bad  Kr's  to  improve. 

•  Small  effective  staff  using  matrix  with  some  degree  of  automation  can  do  a 
tremendous  amount. 

•  During  CE  and  Dem/Val,  the  "long  pole  in  the  tent"  is  how  well  you  prepare 
and  execute  RFP's. 

•  Remember  you  can  agree  to  disagree. 

•  You  can't  systemize  human  relations  and  interfaces. 

•  Good  graphics  of  interaction  -  causes  excellent  recognition  of  where  sensitive 
interfaces  are  required. 

•  People  are  also  resources. 

•  Strongest  interfaces  are  between  PMO,  User,  HHQ's  and  Kr. 

•  PM  really  manages  change  and  the  problems  caused  by  change. 

•  There  are  more  "nays"  than  "yes's"  as  the  PM  goes  up  the  chain.  PM  must 
convince  critics  and  supporters  that  changes  are  (I)  inevitable,  (2)  manageable, 
and/or  (3)  good. 

•  User,  logistics,  Kr,  and  PMO  must  be  rewarded  for  making  realistic 
cost/schedule/performance  tradeoffs.  Because  of  this  they  won't  compromise. 


Executive  Refresher  Course  Comments: 

•  I  don't  think  it  can  be  reduced  to  a  tidy  diagramatic  illustration. 

•  Credibility  with  command  and  staff  most  important. 

•  Don't  feel  it  is  useful  except  in  a  textbook. 

•  No  two  PMO's  or  PM's  are  alike. 
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•  What  has  been  successful  in  successful  PMO's?  Drivers,  trends,  patterns,  etc., 
let's  pass  them  out. 

•  A  good  idea  for  teaching  interface  in  Project/Program  Management. 

•  Hard  to  keep  program  objectives  foremost  in  PM's  mind  much  less  all  other 
organizations  and  individuals. 

0  Communicating  gools/objectives  most  important  job  of  PM.  Model  could  help 
here. 

DSMC  Faculty  Comments: 

0  Phase  0  -  People  emphasis 

•  Phase  I  -  Organizations  dominate 

•  Phase  II  -  Systems  dominate  with  organizations  and  people  important 

•  Phase  III  -  Organizations  dominate  with  systems  important  and  people 
decreasing  in  importance. 

0  PM  does  not  reduce  boundry  density. 

•  Model  is  an  oversimplification. 

0  As  a  model,  it's  OX. 

0  The  model  is  too  abstract. 

•  Interesting  approach  to  general  acquisition  theory. 

•  Boundries  hinder  effectivess  -  Why? 

•  Total  effective  interface  -  Is  this  reality? 

•  Does  a  PM  really  use  models  to  understand  his  responsibilities  in  interface 
management? 

•  Any  PM  should  serve  as  a  staff  officer  at  OSD  or  service  HQ's  -  PM  must  know 
his  way  around. 

•  PM  must  know  when  to  fight/when  to  compromise. 

•  PM  should  be  allowed  to  choose  his  own  staff. 

•  PM  should  know  contracting. 
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PMC  Student  Comments: 
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Good  representation  but  each  PMO  different. 

How  does  this  fit  with  every  PMO  is  unique? 

Model  can  serve  as  a  core  and  uniqueness  stems  from  auxiliary  differences. 

Some  PMss  organize  around  key  personnel  vs.  functional  areas.  As  long  as  they 
were  informed,  the  functions  were  accomplished. 

Kr  and  users  talk  through  PMO. 

Dynamics  are  hard  to  get  a  handle  on. 

There  are  "non-doers"  in  some  PMO's  just  like  other  organizations. 

There  are  no  well  defined  rules  to  work  by. 

Who  is  or/should  be  on  team  -  everyone. 

The  PM  can  only  concentrate  on  a  few  interfaces  at  a  time  -  He  needs  help. 

System  interfaces  are  easy  -  definable  organizational  interfaces  are  fluid  and 
less  definable.  Personnel  interfaces  are  most  difficult  -  change  continuously 
and  frequently. 
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Discussion  of  Selected  Data 


PARTICIPATION.  The  participation  of  those  requested  to  respond  was  more  than 
adequate  with  the  exception  of  the  Executive  Refresher  Course.  I  believe  this  fact  could 
have  been  a  result  of  the  priority  my  research  had  with  respect  to  the  other  activities 
they  were  absorbing. 

ACQUISITION  PHASE.  The  balance  of  involvement  of  respondents  in  different  phases  of 
acquisition  helps  to  validate  the  dimensionality  of  system  acquisition.  Most  were  in  Full 
Scale  Development  (FSD)  or  Production/Deployment  (P/D). 
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SIZE  AND  TURNOVER  IN  PMO.  It  was  interesting  to  note  that  the  Air  Force  consistently 
had  the  highest  number  of  personnel  in  their  SPO's,  while  the  Navy  generally  had  the 
least.  Within  the  PMO's  there  was  an  average  20  percent  annual  turnover  in  personnel. 
This  turnover  factor  can  definitely  affect  the  interface  boundries  due  to  the  need  to 
continuously  bring  folks  "up  to  speed". 

GOAL/ROLE  UNDERSTANDING.  The  most  important  data  received  strongly  supports  a 


boundry  density  concept  and  now  it  is  dependent  on  boundry  factors.  All  respondant 
groups,  with  the  exception  of  PM's,  answered  the  questions  on  the  understanding  of 
program  goals  and  responsibilities  as  less  than  4.0.  The  ERC  was  as  low  as  2.5  and  3.1 
respectively.  This  would  imply  that  there  is  a  general  concern  over  goal  integration  and 
role  ambiguity. 

ORGANIZATIONAL  AND  SYSTEM  CONCERNS.  In  the  area  of  interface  management, 


there  was  general  agreement  that  Congress,  OSD,  the  users  and  contractors  provide  the 
most  organizational  concerns.  While  resources  ($$,  people,  materials),  software,  and 
documentation  and  ILS  provided  the  system  concers.  Resources  are  self-explanatory,  but 
software  could  be  due  to  the  fast  expanding  technology  which  only  a  few  in  management 
have  a  solid  grasp.  The  documentation  concern  could  be  tied  to  the  old  adage,  "the  job's 
not  done  till  the  paperwork  is  finished."  With  the  constraints  on  funding  and  the  increased 
publicity  on  deployed  systems,  an  increased  emphasis  on  ILS  has  evolved.  In  the  last 
couple  of  years,  several  of  our  latest  weapon  systems  have  been  on  T.V.  and  in  the 
newspapers  because  of  ILS  problems. 

SKILLS  AND  KNOWLEDGE.  There  are  a  lot  of  skills  each  group  held  high  in  importance. 
Generally,  leadership,  business  management,  and  communications  were  highest,  while  the 
technical  areas  were  lowest.  There  was  also  some  consensus  on  having  an  understanding 
of  politics  and  needs  or  problem  assessment.  The  lowest  correlation  areas  centered 
around: 


•  Process  Observation 


PM's  and  faculty  thought  it  important 


ERC  and  PMC  students  only  somewhat 
important 


Creative  Thinking 


PM's  thought  >t  important 
Others  only  somewhat  important 


The  remainder  of  the  questions  and  comments  were  primarily  directed  at  the  M- 
DPM  concept  paper.  As  <.  an  be  seen  from  the  original  concept  oaper  and  this  final 
research  paper,  a  large  majority  of  those  comments  either  drove  the  context  and  content 
of  the  research  or  were  directly  included. 


APPENDIX  C 


STEPS  IN  THE  PROCESS  OBSERVATION  MODEL 
INFORMATION  GATHERING 

The  process  by  which  the  organization  gathers  information  about  its  external  or  internal 
environment. 

INFORMATION  GATHERING  addresses  the  following  questions: 

•  Was  all  information  available  to  the  organization  obtained  by  it? 

•  Was  information  recorded,  interpreted,  and  assessed  for  importance? 

•  Was  information  obtained  accurate,  timely,  and  relevant? 


COMMUNICATING  INFORMATION 

The  process  of  transmitting  information  to  those  elements  of  the  organization  who  must 
make  decisions  or  take  actions. 

COMMUNICATING  INFORMATION  addresses  the  following  questions: 

•  Was  information  communicated  to  everyone  who  needed  it  when  they  needed 
it? 

•  Was  the  communication  of  information  complete,  accurate  and  timely? 


DECISION-MAKING 

The  activities  of  one  or  more  persons  leading  to  a  conclusion  that  some  action  will, 
should,  or  should  not  be  taken,  as  a  result  of  gathered  information.  Decision-making  is 
not  limited  to  PM’s;  it  may  include  other  personnel. 

DECISION-MAKING  addresses  the  following  questions: 

•  Was  all  relevant  available  information  used  in  decision-making? 

•  Were  the  decisions  made  at  each  level  correct  in  view  of  information  available 
to  decision-makers? 


Were  decisions  timely? 


STABILIZING 


Actions  intended  to  adjust  internal  operations  to  maintain  internal  stability  and  unit 
integrity  that  might  otherwise  be  disrupted  as  a  result  of  decisions. 

STABILIZING  addresses  the  following  questions: 

•  Were  potential  effects  of  decisions  taken  into  account?  (Accommodate 
change,  new  developments,  other  decisions) 

•  Were  unit  procedures  flexible  enough  to  adjust  to  changed  conditions  and 
situations? 


COMMUNICATION  DECISIONS 


The  process  of  transmitting  decisions  through  a  command,  an  order,  or  instructions  to 
those  parts  of  the  organization  that  must  implement  them.  Includes  discussion  and 
implications  of  those  decisions,  and  attempts  to  obtain  clarification. 

COMMUNICATING  DECISIONS  addresses  the  following  questions: 

•  Was  communication  of  the  decision  complete,  accurate,  and  timely? 

•  Was  everyone  informed  who  should  have  been  informed  about  decisions  and 
requirements? 


IMPLEMENTING  ACTIONS 


The  process  of  implementing  those  decisions  within  the  organization;  primarily  concerned 
with  hos  actions  are  executed. 

IMPLEMENTING  ACTIONS  addresses  the  following  questions: 

•  Was  execution  of  actions  correct  and  effective? 

•  Were  actions  executed  IAW  the  intent  of  the  decisions  and  plans? 

•  What  were  the  effects  of  any  aborted/changed  decisions  and  plans? 


FEEDBACK 


Activities  that  assist  the  organization  to  assess  the  effectiveness  of  its  actions  and  that 
they  provide  information  for  possible  change  or  future  actions. 


FEEDBACK  addresses  the  following  questions: 

•  Was  action  taken  to  obtain  information  about  the  outcomes  of  decisions  and 
actions? 

•  Was  information  obtained  in  follow-ups  considered  in  making  new  plans  or 
decisions? 

•  Was  feedback  information  timely  and  appropriate? 
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TRANSITION  AND  PLANNING  MODEL 


This  Appendix  will  direct  itself  to  a  functional  explanation  of  how  a  program  could 
utilize  the  Transition  and  Planning  Model  as  a  methodology  for  system  navigation  (Refer 
to  Figure  IS).  It  is  strongly  encouraged  that  the  organizational  leader,  in  our  case  the 
PM,  contact  a  service  consultant  for  assistance  in  implementation  of  the  program.  This 
would  allow  the  PM  to  take  an  active  role  in  the  tasks  at  hand  while  the  organizational 
consultant(s)  facilitates  group  interaction.  The  consultant(s)  will  also  be  skilled  in 
assessing  where  the  organization's  concerns  are  so  that  this  model  could  be  effectively 
tailored  to  the  PMO*s  needs  and  expectations. 

The  first  step  is  to  identify  what  values  your  organization  possesses  and  desires  to 
live  by  during  this  next  phase  of  system  acquisition.  This  is  a  time  to  gain  clarity  on  what 
is  currently  happening  in  the  organization  and  understand  reasons  for  the  "deltas"  with 
respect  to  what  is  desired. 

The  next  step  is  to  conduct  on  "organizational  scon"  of  the  PMO  to  determine  the 
demands  on  the  organization.  There  are  three  types  of  demands. 

•  External  demands. 

•  Internal  demands  developed  due  to  external  demands. 

•  Internal  demands  not  associated  with  any  external  demand. 

It  must  be  recommended  that  the  group  should  only  address  those  demands  that  they 
(PMO)  have  control  over  --  planning  and/or  implementing.  Secondly,  the  current  and 
future  state  should  be  discussed. 

After  a  discussion  of  the  organizational  demands,  a  mission  statement  for  the  PMO 
can  be  written  or  revised  based  on  what  the  organization  must  do  —  External  Demands. 
From  these  last  two  discussions,  demands  and  mission,  coupled  with  the  desired  values  the 
PMO  wishes  to  follow,  the  organizational  goals  and  objectives  can  be  determined.  These 
are  defined  as: 

GOALS  Directional  statements  of  what  is  to  be  accomplished; 

qualitatively. 

OBJECTIVES  Specific  steps  to  be  accomplished  which  lead  to  mission  and/or  goal 
attainment;  quantitatively. 

These  steps  should  pretty  well  identify  the  direction  of  the  PMO  and  now  it  is  necessary 
to  determine  how  it  will  get  there. 

The  next  step  is  to  establish  the  organizations  priorities  for  work  effort  within  the 
PMO.  This  can  be  done  by  analyzing  the  demands  on  the  organization  as  they  relate  to 
mission,  goals,  and  objectives.  Since  the  mission,  goals,  and  objectives  are  written  based 
on  the  external  and  internal  demands  listed,  a  mental  prioritization  was  accomplished 
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during  this  discussion.  To  analyze  the  demands,  a  relationship  matrix  can  be  used.  This 
requires  (I)  coding  each  demand  using  the  criteria  below,  (2)  deleting  any  demand  that  is 
unnecessary  (internals),  (3)  listing  for  review  with  external  organizations  those  that  it  is 
felt  are  not  necessary  (external),  and  (4)  establishing  a  priority  for  work  effort  for  each 
demand. 


CODE  MEANING 

1  Mission  essential. 

2  Needed,  but  not  required. 

3  Routine,  nice  to  have. 

4  No  relation  to  mission,  goals,  or  objectives. 

The  deletions  should  come  from  those  coded  //4  and  possible  some  //3's.  At  this  time  a 
review  of  the  mission  statement,  goals,  and  objectives  should  be  made  to  insure  no 
modification  is  needed. 

In  order  to  carry  out  tne  planned  mission,  goals,  and  objectives,  a  PMO  support  team 
will  be  necessary.  Each  member  of  this  planning  session  should  identify  how  they  can 
support  the  transition  by  addressing: 

1 .  What  should  I  do  through  tasks,  actions,  or  functions? 

2.  What  support  do  I  need  from  the  team  and/or  its  individual  members? 

3.  What  support  can  I  provide  to  each  member  based  on  what  they  must 
accomplish? 

Once  a  comparison  and  discussion  has  taken  place,  changes  should  be  made  to  insure  each 
is  now  aware  of  their  specific  roles  and  responsibilities  as  they  relate  to  the  mission, 
goals,  objectives,  and  demands.  The  next  step  is  to  insure  that  no  one  individual  or 
element  of  the  PMO  is  overburdened.  And,  that  the  PMO  and  its  elements  are  adequately 
structured  to  facilitate  the  tasks  at  hand. 

The  next  assessment  should  be  to  study  obstacles  and  people/organizational  resources 
as  they  relate  to  the  previous  work.  This  will  require  an  analysis  of: 

•  What/Who  are  the  obstacles  to  reaching  our  goals/objectives? 

•  What  individuals  or  organizations  a.  e  absolutely  essential  to  achieving  our 
desired  future  state?  And  will  they... 

I.  make  it  happen? 


2.  let  it  happen? 


3.  help  it  happen? 

4.  block  it? 

This  can  be  accomplished  by  completion  of  Table  I. 


A  finol  review  of  roles  and  responsibilities  to  accomplish  the  goals/objectives  and  nullify 
the  weaknesses  will  complete  the  program.  As  a  final  step  to  insure  commitment,  and  the 
most  important,  the  responsibilities  must  be  tied  to  the  organization's  rewards  and 
evaluation  system.  Since  the  team  has  been  involved  in  charting  the  direction  of  the 
organization,  developing  responsibilities  and  team  support  systems,  typing  the  reward 
system  will  insure  implementation  takes  place  and  in  a  timely  manner.  One  additional 
step  that  has  been  most  usefu!  is  for  each  person  and/or  organization  to  develop  an  Action 
Planning  Worksheet  as  in  Table  3. 


PRIORITY 

GOAL/ 

OBJECTIVE 

GUIDANCE/ 

ACTIONS 

DATE 

START 

DATE 

COMPLETE 

Table  3 

Action  Planning  Worksheet 


As  an  organizational  consultant,  this  methodology  was  utilized  successfully  in  many 
organizations  from  small  staff  elements  to  large  civilian  or  military  organizations.  It  is  a 
building  block  approach  to  identifying  mission,  goals,  objectives  and  responsibilities.  It 
also  reduces  boundary  factors  by  gaining  clarity  in  these  areas  and  developing  a  support 
system  among  the  organizational  team.  It  also  has  been  successful  when  utilized  by  the 
"critical  mass"  teams  discussed  earlier  and  pictured  in  Figure  16,  although  not  in  a  system 
acquisition  environment.  A  purpose  of  this  research  is  to  recommend  its  use. 

Some  final  comments.  Automating  the  tables  listed  would  allow  individuals  or 
organizations  to  review  the  status  of  any  specific  task  or  action  so  they  could  determine 
where  the  organization  is  in  meeting  its  goals  or  objectives.  And,  see  if  they  are  required 
to  interface  at  a  particular  point  in  time  based  on  the  plan.  At  minimum,  they  should  be 
reviewed  every  3-6  months.  It  has  been  my  experience  that  the  entire  session  can  take  2- 
5  days  based  on  the  size  of  the  organization  and  the  depth  of  assessment.  The  reviews 
take  two  hours  to  one  day  depending  on  their  frequency. 
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RESOURCES 


Whot  Assistance  ts  Available 


The  depth  a  PM  desires  to  go  into  the  use  of  behavioral  science  skills  in  managing 
the  complexities  of  program  management  are  up  to  the  individual.  Within  each  of  the 
services  there  exists  an  organization  whose  mission  it  is  to  provide  this  expertise,  tailored 
to  the  needs  of  the  organization  and  its  leader  or  manager.  Each  service  has  designed 
their  organization,  instructed  service  members,  and  implemented  programs  focusing  on 
techniques  to  increase  organizational  effectiveness. 

The  Air  Force  has  their  program  at  Maxwell  AFB;  the  Leadership  Management 
Development  Center.  It  operates  on  a  central  consultant  team  concept  where  their 
consultants  visit  various  Air  Force  organizations  to  assist  the  commanders,  leaders,  and 
staff.  The  consultants  administer  a  questionnaire,  analyze  its  data,  and  provide  it  back  to 
the  organization  along  with  their  interpretations.  Based  on  this  data  and  their  interaction 
with  the  leaders,  the  consultants  assist  in  any  type  of  workshops/seminars  that  are 
desired. 

The  Navy's  Human  Resource  Management  Program  maintains  its  school  at  Millington 
NAX,  Memphis,  TN.  They  also  have  regional  HRM  Centers  in  the  following  areas  to 
service  their  installations  and  fleets. 

•  Washington,  DC 

•  Norfolk,  VA 

•  San  Diego,  CA 

•  Pearl  Harbor,  HA 

•  London,  UK 

The  Washington,  DC  office  would  be  in  support  of  all  Navy  activities  in  that  area,  to 
include  the  PMO's  with  NAVAIR,  NAVSEA,  NAVELEX,  and  NAVMAT.  The  Navy's 
program  offers  a  greater  assessment  and  intervention  planning  capability  than  the  Air 
Force.  Although  they  use  surveys  in  the  assessment  phase,  they  are  moving  away  from  a 
dependency  on  that  type  of  data  collection  and  supplementing  it  with  other  forms  of 
assessment.  At  this  time  the  Navy  is  transitioning  its  involvement  to  the  "flag"  level  to 
insure  their  activities  are  making  the  most  impact  for  the  betterment  of  the  Navy. 

The  Army's  program,  Organizational  Effectiveness,  is  the  most  advanced  of  the 
three  services  in  the  use  of  behavioral  science  skills  and  methodologies.  They  have  the 
largest  consultant  force  of  any  organization,  civilian  or  military.  They  train  their 
consultants  at  Fort  Ord,  CA  at  the  Organizational  Effectiveness  Center  and  School.  The 
consultants  are  then  assigned  to  each  post/installation,  major  command,  and  the  Army 
Staff.  The  school  also  maintains  an  External  Operations  Division  comprised  of  senior 
consultants  who  avail  themselves  to  issues  that  have  a  large  impact  on  the  Army  and  its 
missions.  Like  the  Navy,  OE  consultants  can  assist  commanders  or  leaders  in  many 
aspects  of  team  development,  role  clarification,  goal  setting,  and  transitioning.  The 
Army  consultants  can  also  expand  their  expertise  to  advance  problem-solving,  strategic 


E-l 


planning,  and  high  performance  organizational  design.  There  emphasis  is  again  at  the 
command  levels  to  leverage  their  organizational  impact. 

Finally,  the  Defense  Systems  Management  College  sends  its  HRM  instructors  to 
various  DoD  and  service  organizations,  upon  request,  to  assist  in  organizational  improve¬ 
ment.  Not  only  are  they  capable  of  consulting  for  organizations  responsible  for  system 
acquisition,  but  they  also  offer  seminars  and  workshops  for  acquisition  managers. 

Each  of  these  organizations  are  highly  skilled,  have  a  broad  base  of  consulting 
experience,  and  can  be  a  significant  asset  to  a  PM.  And,  with  the  challenge  of  the  '80's  to 
field  new  systems  to  improve  our  defensive  posture,  the  consultant  can  bring  critical  skills 
to  the  system  acquisition  team. 


How  To  Utilize  Organizational  Consultants 

The  role  an  organizational  consultant  takes  when  they  are  working  with  the 
organization's  leadership  is  "to  observe  and  report  in  an  anonymous  and  confidential 
fashion  the  activities  of  personnel  as  they  plan,  execute,  and  supervise  operations.  And, 
to  use  behavioral  science  skills  to  assist  the  organization  in  goal  attainment.  As  a  model, 
this  can  be  seen  in  Figure  25 

In  the  organization  the  PM,  commander,  and/or  staff  leaders  ore  the  real  "change 
agents".  They  identify  a  potential  need  for  change  through  their  own  observations,  or 
observations  by  others,  to  include  the  consultant.  Although  the  consultant  gains  entry 
into  the  organization  at  the  request  of  the  PM  or  commander,  it  is  for  the  organization  as 
a  whole  the  effort  is  being  targeted,  thus  implying  the  consultant  works  for  the 
organization.  As  shown  in  Figure  25,  the  pathway  from  assessment  to  results  can  take  any 
of  the  following  courses: 

1.  The  leader  makes  the  assessment,  provides  feedback,  and  institutes  change 
(I  — * 2  — »4).  The  consultant  serves  as  a  sounding  board  and  makes  recommen¬ 
dations. 

2.  The  leader  makes  the  assessment  and  calls  on  the  consultant  to  assist  in 

organizational  change  ( I  3  — •  A). 

3.  The  consultant  is  requested  to  provide  assessment  data,  it  is  fed  back,  and  the 
leaders  make  the  changes  they  desire  ( I  — *  2  — •  4). 

4.  The  consultant  is  requested  to  provide  assessment  data,  it  is  fed  back,  the 
leaders  use  the  skills  of  the  consultant  in  organizational  change 
(I— ♦2  —  3  —  4). 

The  consultant  can  provide  dynamics  cround  the  leader's  options  or  facilitate 
planning  and  implementation  by  key  personnel.  But  simply  put,  they  can  serve  as  a 
consultant  in  the  leader's  efforts  to  transition  the  organization  from  the  less  desirable 
present  state  to  the  more  desirable  future  state.  This  same  concept  can  work  at  any  level 
of  command  or  leadership  because  the  consultant  is  working  for  the  organization  allowing 
the  leadership  to  become  the  change  agents  for  the  organization. 


ASSESSMENT  OF  ORGANIZATION 
PROCESS  OBSERVATION 
INTERVIEWING 


ASSESSOR  CHANGE  PATH 

AGENT(S) 

Leader  Leader  1—2—4 

Leader  Consultant/Leader  1  —  3—4 

Consultant  Leader  1—2—4 

Consultant  Consultant/Leader  1—2— 3— 4 


Figure  25 

Roles  of  the  Consultant  and  Leaders  in  Organizational  Change 


One  particular  role  for  the  consultant  that  was  initially  a  by-product  of  this  work, 
but  since  has  become  more  intentionally  used,  is  that  of  "calalyst".  First,  the  assessment 
of  organizational  processes  through  interviewing  or  observations  has  an  extremely  high 
catalytic  effect  on  the  sharing  of  information  between  subordinates  and  leaders,  organiza¬ 
tions,  and  individual  staff  sections.  Secondly,  key  leaders  involved  with  the  consultant  in 
process  observation  feedback  and  the  chonge  process  go  through  a  skill  transference. 
They  too  begin  to  make  process  observations  and  enact  change  as  desired  which  enables 
the  consultant  to  address  other  issues.  This  again  lends  itself  to  the  "leaders  as  change 
agents"  concept  because  they  begin  observing  their  organizations  or  staff  sections 
beliavior  and  choose  to  change  those  aspects  that  are  less  desirable.  This 
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catalytic  action  is  present  because  the  leader  is  role  modeling  to  his/her  subordinates  that 
the  use  nl  consultant  skills  in  assessing  the  nigani/otinn  implies  we  as  members  <  on  lulW 
and  take  action  to  change  aspects  we  determine  are  less  desirable. 

An  example  of  utilizing  a  consultant  in  a  PMO  is  depicted  in  Figure  26.^® 


PM 


PM- 


STAFF 


CONSULTANT 


INDIVIDUALS 


STAFF 


GROUPS 


Consultant 

TASKS  TO  BE  PERFORMED 

•  Assess  the  organizations  and/or  individuals  as  to  how  they  interact. 

•  Observe  the  functioning  of  organizations  and/or  individuals. 

•  Provide  feedback  to  key  personnel. 

•  Facilitate  discussions  or  structured  sessions  based  on  the  PM's  desires  after 
reviewing  feedback.  They  may  also  be  performed  for  staff  and  other  leaders. 

•  Serve  as  a  catalyst  to  improve  the  sharing  of  information. 

Figure  26 

How  the  Consultant  Interfaces  in  a  PMO 
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I  must  comment  that  my  experience  with  organizational  consultant  comes  from  four 
years  with  the  US  Army  Organizational  Effectiveness  Program  and  work  with  public  and 
private  organizations.  I  have  had  limited  interface  with  the  Air  Force  and  Navy 
programs,  but  their  methodology  is  similar  to  what  I  have  described.  Each  consultant, 
civilian  or  military,  who  is  worth  his/her  salt  will  be  up-front  about  their  capabilities  and 
place  your  organizational  desires  ahead  of  their  personal  concerns.  They  should  also 
utilize  a  Memorandum  of  Agreement  as  to  their  involvement  in  organizational  change  and 
how  they  will  interface  with  the  PM  and  the  organization.  The  PM  or  organizational 
leader  should  also  document: 

•  What  are  his/her  expectations. 

•  How  should  feedback  be  given  and  at  what  intervals. 

•  To  what  depth  should  the  consultant  activities  go. 

•  What  will  or  will  not  be  addressed  and  why. 

•  How  will  follow-up  be  accomplished. 

This  MOA  will  provide  a  basis  for  the  conduct  of  the  consultant  operation. 

Again,  I  wish  to  emphasize  the  consultant  resources  of  the  military  are  almost 
unequaled  in  skill  and  utility.  A  most  valuable  resource. 


References  to  Consult 


The  following  references  can  provide  additional  information  on  organizational 
development,  the  use  of  consultants  and  facilitators,  and  general  management  theory. 


•  French  and  Bell 

•  Huse  and  Bowditch 

•  Hersey  and  Blanchard 

•  Huse 

•  Kast  and  Rosengweig 

•  University  Associates 


Organizational  Development:  Behavior  Science 
Interventions  for  Organizational  development, 
1978. 

Behavior  in  Organizations:  A  Systems  Approach 
to  Management,  1977. 

Management  of  Organizational  Behavior: 
Utilizing  Human  Resources,  1977. 

Organizational  Development  and  Change,  1975. 

Organization  and  Management:  A  Systems 

Approach,  1974. 

The  Annual  Handbook  for  Group  Facilitators 
Team  Building:  Issues  and  Alternatives,  1977. 


•  Dyer 


•  Kepner  and  T regoe 


The  New  Rational  Manager,  1981 


•  OEC&S  The  OE  Communique,  Quarterly. 

•  The  references  of  this  research. 

Many  of  these  books  and  periodicals  are  located  at  the  offices  of  your  service  consultant 
organizations.  They  can  also  be  found  in  the  libraries  of  major  universities. 
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DELTA  FORCE-THE  CONCEPT 


Delta  Force  is  a  voluntary  group  of  American  soldiers  and  citizens  who  contribute 
ideas  for  improving  our  Army.  It  is  informally  organized— both  an  organizational  "ring" 
chart  and  a  mailing  roster  are  maintained— but  not  hierarchically  structured.  Members 
dedicate  their  diverse  talent  and  expertise  to  the  problem  statement:  "Understanding 
that  we  work  through  people,  how  can  our  Army  improve  its  ability  to  plan,  equip,  man, 
run,  train  and  fight,  now  and  in  the  future?" 

Organization.  Because  personal  competence,  moral  courage,  candor  and  commitment  are 
the  values  sought  in  each  member,  the  characteristics  of  the  individual,  rather  than  the 
position  the  individual  occupies,  is  the  criterion  for  membership.  Many  academic  and  job 
area  disciplines  are  represented  on  delta  Force.  Strength  in  diversity  and  a  variety  of 
experiences  and  abilities  gives  Delta  Force  its  capability  of  providing  cross-disciplinary 
objectivity. 

Delta  Force  is  administered  by  the  Director  of  the  Army  Staff  through  the 
commandant,  US  Army  War  College,  at  Carlisle  Barracks,  PA.  The  Commandant 
maintains  a  small  staff  consisting  of  a  director  (Colonel),  deputy  director  (Lieutenant 
Colonel/Major),  admin  NCO  (Sergeant  first  Class)  and  two  secretaries,  to  run  the  Delta 
Force  nucleus  located  at  Carlisle  Barracks.  The  nucleus  manages  Delta  force  and  does  a 
clearing-house  function.  It  synthesizes,  edits,  reproduces  and  distributes  concept  papers 
from  and  to  the  member-..  It  conducts  three-day  conferences  for  members  about  once  a 
quarter. 

Membership  on  the  "ring  chart"  (the  Delta  Force  organization  chart)  consists  of 
about  85  citizen-,  military  and  civilian.  Membership  is  dynamic.  As  old  members  leave, 
new  members  who  have  demonstrated  competence,  courage,  candor,  commitment,  and 
expertise  are  added.  Membership  is  determined  by  the  director  of  Delta  Force,  with 
approval  by  the  USAWC  Commandant. 

The  Delta  Force  mailing  list  more  accurately  portrays  working  membership  than  the 
ring  chart.  The  current  mailing  list  of  over  130  entries  includes  the  ring  chart  plus  those 
who  have  expressed  an  interest  in  Delta  Force's  activities  and  products.  Most  people  on 
the  mailing  list  contribute  their  time  and  talent  even  if  they're  not  listed  on  the  ring 
chart. 

Modus  Operandi.  Delta  Force  deals  in  ideas— concepts  which  answer  the  question  posed  by 
the  problem  statement.  We  communicate  these  concepts  with  the  Delta  Force  Concept 
Paper.  Each  concept  paper  is  shared  with  everyone  on  the  mailing  list.  Each  member  is 
asked  to  give  his/her  views  on  it— a  process  resulting  in  cross-disciplinary  objectivity.  The 
original  concept  developer  then  rewrites  the  concept,  advantaged  by  the  collective 
critique  of  other  Delta  force  members.  We  then  pass  the  resultant  concept  on  to  the 
appropriate  Army  agency  for  information/action. 

We  also  enter  concepts  into  a  computer-assisted  conference  network  for  comment 
and  vote  by  participating  Delta  Force  members.  Operating  with  portable  terminals  and  a 
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telephone  connection,  members  can  have  any  concept  printed  out  in  hard  copy,  enter  a 
critique  of  the  concept,  and  view  all  other  critiques  that  have  been  entered.  We  intend  to 
eventually  replace  the  mailing  system  with  the  computer  conferencing  system.  It  is  more 
timely,  flexible  and  efficient.  Its  potential  is  limited  only  by  the  availability  of  portable 
terminals. 


THE  SUBJECT 

Delta  Force's  problem  statement,  "Understanding  that  we  work  through  people,  how 
can  our  Army  improve  its  ability  to  plan,  equip,  man,  run,  train  and  fight,  now  and  in  the 
future?",  is  extremely  broad.  We  categorize  concepts  into  one  of  seven  study  thrusts 
covering  four  functional  areas: 


Preparing  I  II  III 

Peacetime  Operations  IV  V 

Wartime  Operations  VI 

Future  VI) 


I.  Planning  the  Force:  Includes  unclassified  issues  about  military  planning  as  a 
function  (planning  jn  the  force),  force  structure  planning  (what  kind  of  force  we  will 
have),  contingency  planning  (how  we  will  use  the  force),  and  planning  theory  and  practice 
(planning  for  the  force). 

II.  Equipping  the  Force:  Includes  issues  about  combat  developments  of  materiel 
and  equipment,  proposed  hardware  systems  and  associated  man-machine  interface  issues. 

III.  Manning  the  Force:  Includes  issues  about  personnel  life  cycle  including 
recruitment  and  retention  and  issues  about  personnel  policy  formulation  and  impact. 

IV.  Running  the  Force:  Includes  issues  about  how  we  run  our  Army  Organizations 
including  the  human  dimension,  effects  of  change,  the  science  of  systems,  command  and 
control,  and  information  flow. 

V.  Training  the  Force:  Includes  issues  about  all  types  of  Army  training  and  the 
training  systems  that  support  it. 

VI.  Fighting  the  Force:  Includes  issues  about  who,  what,  how,  when,  where  and 
why  of  Army  combat  and  force  readiness. 
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VIII.  The  Future  Force:  Includes  issues  about  how  our  Army  will  plan,  equip,  man, 
run,  train  and  fight  its  forces  in  the  extended  and  near  future. 

Although  Delta  Force  has  experts  in  each  of  the  seven  categories,  members  are  not 
limited  to  issues  of  their  own  particular  expertise.  In  matter  of  fact,  the  power  in  the 
Delta  Force  method  of  concept  development  results  from  cross-disciplinary  critique.  A 
training  developer  gets  advice  from  a  stress  expert— a  combat  developer  gets  help  from  a 
futurist.  In  this  manner,  unintended  second  and  third  order  effects  have  a  higher 
likelihood  of  a  priori  discovery. 

Working  the  Problem.  Delta  Force  is  both  supply  and  demand  driven.  We  encourage 
members  to  originate  conceptual  solutions  to  the  problem  statement  based  on  their 
professional  knowledge  and  experience,  however,  demands  in  the  form  of  issues  developed 
through  the  DAS  and  the  Commandant  are  the  primary  catalyst  for  Delta  Force  concept 
development.  In  keeping  with  the  problem  statement,  issues  are  wide  ranging,  both  in 
subject  matter  and  impact. 

Delta  Force  is  not  the  proponent  for  anything.  It  deals  cooperatively  with  those 
agencies  whose  proponent  responsibilities  include  planning,  equipping,  manning,  running, 
training  and  fighting  the  force.  After  a  concept  is  completed,  it  is  passed  to  appropriate 
individuals/agencies  for  their  disposition.  To  avoid  proponency  conflicts  and  maintain 
independence  and  freedom  from  bureaucratic  constraint,  Delta  Force  purposely  does  not 
take  "credit"  for  any  action  its  concepts  initiate. 

Contact  for  further  information: 

Delta  Force 

Box  I,  US  Army  War  College. 

Carlisle  Barracks,  PA  17013 

AUTOVON:  242-4201/4203 

COMMERCIAL:  (717)  245-4201-4203 


NOTE:  This  Appendix  is  a  reprint  of  the  DELTA  FORCE  Concept. 


END 
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